Systems engineering and PLM
From the perspective of AUCOTEC
The whitepaper is based on a discussion with Reinhard Knapp, who has been with AUCOTEC AG in Hannover since 1989, initially as Development Manager, then since 1996 as Product Manager. He was actively involved at the time when AUCOTEC was, as he says, a one-product company, namely with Elcad.
Today, Mr. Knapp is responsible for product strategy which has for several years mainly focused on the IT support of Systems Engineering.
At a glance
- The current product from AUCOTEC is Engineering Base, a platform that was designed from the beginning for Systems Engineering. Here, the circuit diagram is no longer at the forefront; it is only one of several possible representations of a system.
- Systems Engineering has been a highly strategic subject for AUCOTEC for many years. The company believes that industry is still in the early stage of its usage and that it is of immense potential significance to all involved.
- The most important target markets are sectors with products that move – cars and commercial vehicles through to ships, airplanes and trains and even including rockets and satellites. In addition, many important customers are to be found in the process industry and in plant engineering.
- The main focus of AUCOTEC is on the complete networking of the electrical and electronic components of these products, across the full gamut from requirements to simulation and validation.
- In the coming years, the implementation of Vehicle Electric Containers (VEC) with Engineering Base is on the agenda.
- In the long-term, AUCOTEC believes that with the help of Engineering Base, work will no longer be document-based (and in fact mainly related to the graphics) but will involve direct usage of all information and the relationships between all the components of a system.
Systems engineering, and what it has to do with PLM
The importance of systems enigneering
When Engineering Base was developed at the end of the 90s, purely graphical data processing methods were, in the eyes of the developers, fast approaching their limits. It was no longer possible to delineate increasingly complex systems such as those for cars or airplanes (on which many employees simultaneously worked in large groups) by assigning attributes to a drawing. Electro-technical/Electronics development departments needed a platform that treated the relationships between the components as the main factor, with a specific representation being secondary. The impetus for this came from customers in whose products electro-technical/electronics components were playing an ever-increasing role. In the beginning, this primarily consisted of interaction between these components and the mechanical parts, but in more recent years software took on a leading role.
Even within the individual subsystem, the geometry, or a particular unit, is no longer the center of attention – the focus now being directed at the networking. A window lifter in a car is now networked with the door locking system, which is in itself a complex subsystem. The cabling of the system and its connections to surrounding systems is no longer decisive. The function, and the relationship to higher-level system functions, is now more important than the hardware.
This is why Systems Engineering is also of strategic importance to providers of Engineering IT whose main interests lie in electro-technical equipment. None of the professional disciplines involved in modern system development can avoid this trend and standard software for engineering will in future be measured on how well it supports Systems Engineering in every discipline. That it must be able to handle the tasks specific to that discipline is seen as being self-evident.
Systems Engineering und PLM
Product Lifecycle Management has developed from the – one should perhaps say ‘earlier’ – main discipline of machine building. The mastery of the mechanical aspects, their geometrical design and kinematics, and the construction and management of a complete product structure that finally resulted in the manufacturing bill of materials was the starting point for product data management – the origin of PLM. Only recently, in the last two or three years, have the major systems from PLM suppliers started to concentrate on the relationships between the mechanical and non-mechanical components. As Reinhard Knapp notes, “the element ‘wiring harness’ is still pretty new for these systems.”
(Cable harness manufacturing, image source: AUCOTEC)
In electro-technology and electronics, in contrast, the relationships between the components always played a major role. The logic of these relationships and the function of the individual component were the goal in the design of the wiring harness in all its various aspects. This is why, in the development of Engineering Base, the relational database behind the parts was included as an integral part of the platform right from the beginning.
If PLM is also to include the development of electro-technology/electronics, and the software and also the management of the data that is created in all these disciplines, then it becomes clear that this is not just about integration of components into a bill of materials, but about subsystems with an already well-understood and specific array of relationships.
AUCOTEC supports both – working with Engineering Base as an authoring system whose results are then input into a large PLM system; and also the overall use of the database as an independent, lightweight technical PLM system in conjunction with the authoring system.
Vehicle industry and plant engineering
Vehicles and other moving product systems
The degree of maturity of methodical system development is in no sense uniform across the various sectors of the manufacturing industry. These are sectors that started at different times and the system plays a different role in the respective products.
(Satellite development, image source: AUCOTEC)
The ideal task setup for top-down development is a fundamentally new development of an individual system. This, however, only occurs in a few special sectors, for example aerospace and satellite construction, which was actually the origin of Systems Engineering. Sometimes only a single M-CAD system is implemented there in addition to Engineering Base. In such cases, recording the requirements and defining the functions takes place at the beginning of the system design, which is then broken down with regard to the subsystems. This means that the system model is available from the first concept onwards and future development can be measured against it, tests and simulations can relate to it, and that it also permits validation of the developed hardware and software.
Here, system development begins with a functional block diagram followed by a physical block diagram. If the wiring harness is then split out and connected to various devices, this takes place within a single data model that contains the signal networking as well as the topology, and one that permits, for example, simulation of the voltage drop on a line across all of its connection points. A noteworthy AUCOTEC customer in this field is Astrium, which develops satellites and launch vehicle assemblies.
Things look completely different in sectors such as the automobile industry. Vehicle development generally means changing existing types, creating variants and the replacement of mechanical functionality by electro-technical/electronics and software functionality, or adding new functionality by means of new systems. And the largely automated manufacture of millions of vehicles must also be taken into account. The various departments still use many systems from a large variety of manufacturers, both in the mechanical and other disciplines. A top-down approach can only be considered in a few exceptional cases. Systems Engineering helps, however, to keep the enormous number of vehicle type variants under control. The entire onboard wiring system of the current Porsche 911, for example, was completely developed using Engineering Base.
A single vehicle has no individual documentation. Instead, planning assumes the so-called ‘150% of functions and fitted components’, although in reality these are never all fitted. The specific customer wish is in fact implemented in a bill of materials that only contains those parts needed to fulfill this wish.
Airplane-building is yet again different. Volume production does take place here, but each individual aircraft must have its own complete set of documentation.
Engineering Base permits the customer to always create an individual set of documentation for the systems developed on the platform. This can be done because all of the relationships between the individual elements of the system that are actually used are defined, and the documentation for each specific variant – with or without a stereo system, with or without a navigation system– can automatically be derived from these.
The process industry and large-scale plant engineering have also thought in terms of systems for a long time, even though Systems Engineering, systems and subsystems are seldom talked about, the terms used tending more to be blocks and plant sections. Large plants have an extremely long lifecycle and over this period they actually ‘live’ – in comparison to vehicles. In other words, they change over time. A block is added here, while there another is replaced by a more modern version. In plants, documentation also plays a different role that in itself has changed in recent years due to the increasing use of Systems Engineering. Up to several years ago it was generally the case that three, four, sometimes even five years were needed until the documentation actually represented the ‘as built’ condition. Today it is produced – when Engineering Base is used – automatically at the same time as the development data is approved.
Some AUCOTEC customers actually use Engineering Base for overall product lifecycle management. They link the software, for example that of the plant control system, directly to the signal components.
Methodology and next steps
The starting point for all systems engineering is the functional requirement. In the aerospace and automobile industries the use of Doors and other standard software products has become the norm. From Reinhard Knapp’s perspective, however, the requirements that are recorded and administered in this way can only in a very few cases be linked to downstream development steps. Requirements, and Requirements Engineering, tend to exist on their own completely independent of the actual system development.
AUCOTEC sees here a great deal of potential that can only be realized, however, when the customers themselves have recognized the advantages. Knapp observes “the problem is the granularity of the requirements. Due to the way that they are initially recorded and described, they are at a highly abstract level. They can only be used for system development when they have attained the practical level of the device or the subsystem. So here the work is often carried out all over again and the requirements and function diagrams redefined with the necessary fine granularity. However the hardware components that are developed based on this procedure have generally no direct and verifiable relationship to the original top-level requirements.”
Everything from a single source?
In response to the question whether Systems Engineering can be better realized within an open IT environment or with completely integrated systems, AUCOTEC has two answers: On the one hand it is clear that only with and end-to-end data model is validation, for example the V Model, truly possible. The most desirable applications are as a result those in which the requirements – up to and including testing – can all be implemented in Engineering Base. On the other hand, these represent the greatest exceptions, because almost nowhere are only one or two systems in use – the IT environment has grown up across many years and that is the normal kick-off situation as regards Systems Engineering.
Because of this fact, from the perspective of AUCOTEC there is a great deal of interest in aiming for standardized system descriptions. The company is therefore actively participating in the Vehicle Electric Container (VEC) project for the networking of signals for automobile industry wiring systems that the VDA is developing in conjunction with the ProSTEP iViP Association.
Reinhard Knapp points out “When standard objects, i.e. the cables, the plugs, the attachment elements, the topology and the functions have once been defined in VEC, a simple mapping of our Engineering Base objects onto these is more than sufficient. Then we don't need a difficult-to-maintain interface to every system involved. What the ProSTEP iViP Association is making is a sort of glue that we need for the interaction of the many tools in Systems Engineering.”
It is therefore no coincidence that one of the most important steps in the coming years is the practical implementation of VEC with Engineering Base. For this purpose, a larger pilot project has been agreed with one of the German automobile manufacturers that will start in 2012 and should complete in 2013.
Moreover, when Reinhard Knapp looks a little further into the future, he sees a time approaching in which it may be possible to entirely do without the creation of graphical plans for many system development tasks. After all, the entire information, geometric and graphical and alphanumeric representations are logically and functionally linked to one another in Engineering Base. This implies that all development steps can be immediately, and to a great extent automatically, derived from this data.
Users, however, will first have to be convinced of this. When all is said and done, they have, across the decades, learned to communicate in terms of circuit diagrams and graphical representations. For AUCOTEC this is a huge opportunity – one that very few indeed have taken advantage of up until now.