What do programming skills have to do with engineering?
With companies taking more interest in design automation tools to remain competitive and improve efficiency, engineers must be prepared to learn new skills which include both product management and one or more programming languages.
Design automation is a bit like the evolution of CNC (Computer Numerical Control) machine tools back in the 40’s and 50’s. Before this time parts were turned or milled on machines controlled manually by skilled machinists regardless of the number of parts required. Nowadays, CNC machines would complete repetitive parts using a computer programme to reduce time, cost and ensure accuracy. Design automation will evolve in a similar way, the repetitive work of the design engineer will be automated.
Many companies still employ large teams of engineers to carry out iterative changes to existing products combining pre-engineered features and options to meet customer requirements. The engineer’s job being to provide layouts and details of standard equipment reflecting unique configurations of the company’s standard components. Now that it is known that product configurators can take care of this work, the engineer must choose to either embrace this new technology or to see their jobs replaced by computers.
Product configurators provide the ability to select from millions of permutations with total accuracy, following the pre-determined rules that the company wishes to apply. They not only provide the product configuration, they are now capable of providing commercial information such as quotations, drawings, specifications, electrical circuits, and instruction manuals to name a few. They do these tasks with ruthless efficiency, providing virtually instantaneous results.
Once it becomes clear that a product configurator can be used to automate the design of a product, employees are very likely to become fearful and resistant to change. Comments such as “what happens to my job when this configurator is up and working?” are reasonable given the number of hours that can be saved, and the efficiency gained.
I believe that over the next decade companies will think it absurd to employ skilled engineers to carry out iterative changes to configurable products in the same way that nobody would consider turning endless parts manually on a lathe. Foreign competition is forcing increased efficiency, it is only a matter of time before product configuration becomes the norm, not the exception.
Why not use existing tools?
I have a great deal of respect for Glen Smith and the team from DriveWorks who in 2001 introduced a product configurator to automate the repetitive tasks for SolidWorks users. DriveWorks provides a robust configurator that closely integrates with SolidWorks. DriveWorks provides the means to automate design tasks without the need to learn a programming language and to produce documents such as sales proposals without the need to enter further details. Autodesk have also attempted to release their own configuration software with Configurator 360 and Fusion, however these products are still in their infancy.
Several of my clients wish to employ product configurators that interface closely with their existing processes. They want systems that integrate fully with their sales, engineering and production systems. Their appetite for automation reaches far beyond the need for a 3D models and a quotation, to complex process documentation, even the automation of the software required to be written to operate the machines in the factory.
As companies look for new areas of competitive advantage, design automation will become an increasingly important area of interest. Where companies are prepared to adapt their business processes, solutions such as Driveworks offer a fast and reliable way to configure products. Where the company’s systems are deeply established, the design automation systems need to be written to closely integrate with those existing processes.
Before a product configurator can be implemented the engineer must ensure that the product is configurable. This requires planning to ensure the products can be resized and new options or features added without fundamentally changing the product design. Ideally the product should be considered like the toy Lego, where millions of assemblies can be constructed from a small selection of interconnecting blocks. To reduce complexity, it is usual to break some of these large assemblies down into smaller sub-assemblies before configuration starts.
One large element of the product configurator is its capture of knowledge. All the rules and specifications of a product can be set in stone so that every iteration complies with a strict set of parameters. These can rules vary greatly in complexity but are essential if the configurator is to safeguard build integrity and to achieve the desired results. Whilst this must be set up by an engineer who understand the build and its requirements it can then be used by more novice users, with the tools rules guiding their configuration. Knowing how to turn engineering knowledge into set coded rules will be very important in a burgeoning use of configurators, allowing great flexibility and time saving potential. But there are tools out there that already augment modelling skills, why learn a programming language to do this?
It is virtually impossible to do business these days without the use of a computer. Engineers rely upon the precision and speed that is achieved using design software, yet very few harness the true capability that that software has to offer. Some design software companies such as Autodesk provide an engineer friendly interface which allows engineers to automate simple tasks. Tools like iLogic are designed to allow engineers to make changes and interface with computer aided design (CAD) software without needing to learn a programming language. Its true that some companies have achieved some very impressive results writing complete applications with nothing other than iLogic.
Yet, to achieve full control of both the CAD interface and other applications, it will be necessary to address the CAD active programming interface (API) directly and this requires the use of a programming language such as C# or Visual Basic.Net. Once connected to the API, the programmer has access to virtually every area of the CAD interface. From here the process of product configuration becomes achievable. Data can be passed to the API to drive the model, and from the API to qualify decisions in the configurator. At the same time data such as costs can be accessed from a secure database, and reports assembled and formatted using office software. Furthermore, working with a full programming language offers far more tools for checking and testing the rules for your configurations, safeguarding your configurator for the future and against the possibility of user error.
Engineers, not programmers need to construct and maintain product configurators, for it is the engineers that have the core knowledge required to make use of these configurators. The product configurator should be considered as part of the product definition and not a detached application. Whilst it would be possible to have programmers supporting engineers, this adds unnecessary communication and time in the design process. This avoids the engineer being totally reliant on the programmer whenever there is the necessary for change. It is far better that the engineer learns a programming language so that he/she can create, extend or modify the configuration system whenever the product changes.
Where to begin?
Currently there are no useful text books detailing how to write product configurators for the mainstream CAD software, and information needs to be researched from several sources. There are useful sources of information available on the internet, some reliable, some not. The engineer will need to develop his own library of programming commands which achieve the control he requires. I am sure within a few years this knowledge will become more accessible. Management needs see the scope of what configurators can do and proactively train their engineers to pick up on this new skillset. Specialists can help coach during the early stages and provide reliable code to accelerate and reduce the need for extensive and costly research. From experience, engineers are usually very quick to learn sufficient programming language to extend or maintain a product configurator. It takes considerably longer to become a good programmer.
For many years computer programming has been a separate discipline, but as design becomes more dependent upon computers the demarcation of the skills becomes blurred. It is generally easier for an engineer to learn a programming language than for a programmer to learn to become an engineer. To learn now would give a competitive edge, but I believe in the future programming will be a key skill, not just for engineers, but for almost everybody.
Written by Peter Slee Smith, Editted by Jason Spencer – 20/03/2018