Engineering Toolbox
Engineering processes are characterized by a high degree of structuring, clear methodology and standardized procedures. However, relying on these alone is often no longer enough for a company to be successful in competition. Successful companies pursue innovative approaches to solutions and often do things not just “better” but fundamentally differently.
In the skilled trades, a saying goes, “Good tools are half the work.” This is just as true for engineers, although these days the tools are increasingly software solutions. Most engineering processes are hardly imaginable without suitable software support. In many cases, extensive standard systems from renowned manufacturers are used.
Standard tools versus unique selling points
How can the claim of “doing extraordinary things” and “doing things fundamentally differently” be reconciled with the use of standard products? First of all, we don’t see any contradiction in this. Many steps in engineering processes involve standard tasks for which there are proven procedures. For these purposes, the use of standard products is efficient and resource-saving, in keeping with the guiding principle “don’t keep reinventing the wheel”.
However, even the best tool suites reach their limits. Especially at the transitions between different organizations or extensive systems, gaps often occur. Closing these gaps usually involves a great deal of manual effort and is therefore error-prone and time-critical.
A loss of efficiency is annoying, but it becomes critical when the standard procedures available in the product are not sufficient and new, innovative procedures and methods provide a decisive competitive advantage. The following questions then quickly arise:
Can the ideas even be implemented in the desired form with the standard product? Is this possible in a reasonable time frame with justifiable costs?
Is there an opportunity to test out the new process, develop it iteratively, improve it, and incorporate newly gained knowledge during the development process?
Do I want to see competitively differentiating know-how integrated by the manufacturer in its product, where it may also be available to others? Or do I keep it secret and integrate it myself, but then also be responsible for further development during release updates?
The goal: A flexible engineering toolbox
This is where our Engineering Toolbox approach comes in. We complete the software toolbox of engineers with specialized, combinable tools based on open interfaces and standards. Our focus is to build on existing solutions and integrate new functions as building blocks in order to move forward quickly and effectively. In our experience, these can be roughly divided into two (not always clearly defined) categories:
Integration tools bring together data from different sources and transform or aggregate it so that it can then be passed on to other systems or processes.
Enabler tools implement a specific process or new method for which no suitable IT support previously existed. Examples include the validation of data, the verification of design rules, the automation of a specific design step or specific calculation methods, and individual visualizations.
In most cases, such special tools are created to cover a specific need. In many cases, additional requirements and benefits subsequently arise because the new functionality also brings benefits in other processes or because new possibilities are recognized in the course of the project - “eating whets the appetite”. In the long term, the opportunity arises to build up a modular toolbox of versatile individual tools that can be flexibly combined.
To identify and leverage such potential, we recommend an agile project approach. This allows us to react quickly and flexibly to iteratively develop new capabilities based on user feedback. The scenarios are as diverse and individual as our customers.
There are many options when choosing a suitable technology stack; however, it often makes sense to implement the tools as web-based microservices. This has various advantages:
Automation potential: when implemented as a web service, the functionality is available to other systems for automation.
Good accessibility: Users gain access via a normal web browser. No software needs to be installed.
Integration: A web service in its own infrastructure is not limited to user input or a single data source, but can use and integrate different data sources.
Flexibility: Adaptations and extensions are possible quickly and easily.
IP protection: By implementing it as a standalone service, the know-how remains in-house. If the implementation is web-based, this further increases protection against unintentional copying and distribution.
Many of the systems we develop for customers are inherently confidential. A representative example we can present is the Harness Navigator.
Harness Navigator
In the Harness Navigator, two worlds collide: the world of geometric design unit (DMU) analysis and the world of electrical connections including equipment variance in the physical vehicle electrical system. Both are being developed independently of each other for the time being.
The original challenge was to enable installation space investigations for specific variants of a wiring harness. For this purpose, the “empty” geometric shell of all variants had to be combined with the logic and knowledge of equipment variants.
The resulting solution consists of two components:
A converter as an integration tool that makes it possible to intelligently link wiring system data in the standard formats KBL or VEC with 3D data in the standard format JT. Originally, the converter was only intended as a standalone tool; in the meantime, it has been firmly integrated into the customer’s IT landscape as a service.
A remote control (the actual “Harness Navigator”) as an enabler tool that allows standard 3D viewers to be “remotely controlled” based on on-board knowledge. This allows standard 3D functions such as “fade in/out” and “highlight” to be triggered by logic specifically tailored to the physical on-board network.
By cleverly integrating existing products, it was possible to support the special case of wiring harnesses and at the same time use the established functions, e.g. for collision checks in the DMU.
The new ability to dynamically drive the 3D model based on domain knowledge then led to a number of other ideas. For example, coloring can be used to determine at a glance whether design rules such as the separation of redundant line runs are ensured. Even more possibilities subsequently emerged through the integration of additional data sources on vehicle configurations, signals and critical lines.
