Systems engineering and PLM
From the perspective of PTC
This whitepaper is based on a talk with Andrew Wertkin, the Chief Technology Officer (CTO) of the PTC Integrity Business Unit. Integrity is the name of the product – taken over when PTC acquired the supplier MKS in June 2011 – that targets application lifecycle management (ALM) in software development. Andrew Wertkin was previously CTO at MKS.
Before holding this post he was joint founder and CTO of Synapsis Technology, a company that supported compliance in product development from the technical software perspective. Synapsis was acquired by PTC in 2008.
Andrew Wertkin studied bio-engineering at the University of Pennsylvania.
A brief overview:
- With MKS, PTC acquired a system – Integrity – for application lifecycle management. Sales will for the moment continue to be for complete systems supplementing the PLM tools, particularly Windchill and Creo
- With regard to Systems Engineering, PTC sees that an important requirement of the market is to remain open and support all the tools used by customers from different suppliers for modeling, analysis, test and simulation
- The most important functions that PTC offers for Systems Engineering are:
- Requirements Engineering and Requirements Management
- Test setup and test management
- Documentation of all models, tests and simulations on the basis of the requirements
- Traceability of the entire system development based on requirements
- Integration of Systems Engineering into PLM
- The roadmap for further development and integration of PLM and ALM will be agreed with a global advisory panel of PTC customers
The importance of Systems Engineering
Systems Engineering has a high priority for PTC. From Andrew Wertkin’s point of view, the times when software was just an additional point in the BOM are past. Whereas for PLM the BOM was at the core of things, today the system is on the way to taking up that position. Everything else – the BOM, the part and even the product components – are now part of the system. And this makes Systems Engineering a strategic topic for PTC, and one in which PLM plays a role.
Systems Engineering itself is already around 60 years old and originated in the worlds of aerospace and defense industries (known as A&D). Compared to their predecessors, however, today's systems are considerably more complex. The drivers of this increasing complexity are on the one hand the trend to realize more and more innovations by means of software, and on the other the fact that modern products increasingly communicate and interoperate both with one another and with their environment. John Deere, for example, no longer talks of agricultural machinery but of high-tech agricultural solutions linking up to satellites and possessing integrated GPS.
As well as the complexity, the pressure for higher quality requirements and legislation are also important drivers that are forcing industry to look seriously at Systems Engineering.
Relevance to industry sector
The tendency described above applies across the board for almost all industries. This is why in the eyes of PTC there are no special industrial sectors requiring the support of Systems Engineering. However regarding the maturity of the methodical procedures, one can observe large differences. Many companies do not yet run proper requirements management. Requirements often differ in meaning only due to the fact that they are written in a bold font or otherwise in a text document. Conversely, however, some companies have been long aiming at an end-to-end process chain in Systems Engineering. The approach to customers by PTC must accordingly vary in its nature.
In high-tech electronics, Requirements Management and the validation of the requirements are in the foreground. Aerospace has been familiar with this subject for the longest time and are the main drivers of attempts at standardization. Today however, the automobile industry seems to be furthest ahead with regard to the methodology. Here, Requirements Engineering is standard. Currently it's all about the linking of the domains and the chaining of processes from the concept, through change management test and validation, and on up to the customer.
Requirements Engineering – the core of system development
For PTC, the most important phase in system development is that which appears at the very top on the left in the V model, namely the phase in which the requirements on the product are recorded and a suitable system architecture to accommodate these is designed. Andrew Wertkin notes that “only when this is handled methodically and thoroughly can the correct decisions for the analysis of the system and any variants be made. The ‘whys’ of Systems Engineering find the justification for their answers here. All the decisions in the following processes depend on the correct definition of the core in the concept phase and the correct design of the system. For this reason, we focus on us above all supporting the initial decisions that are made, before any kind of software – and certainly hardware – is developed. Until now, this phase especially has been largely decoupled from PLM.”
Integrity has its own comprehensive module for Requirements Engineering that Andrew Wertkin finds comparable to DOORS from IBM in its functional scope. As in the past, PTC does not market MKS as a separate module. The strength of Integrity lies exactly in the integration of all important parts of the system and particularly in the fact that Requirements Engineering represents a comprehensive foundation for all other steps in system development.
Andrew Wertkin gives an example – “some suppliers regard the reuse of parts or source code as simply a question of copy and paste. They help the user to find certain already developed objects quickly and then clone these for some purpose and reuse them. Doing it this way, however, can mean that errors are inherited – or that a variant or a modification of a component is used that was only ever intended for a specific purpose. In contrast, we already build a proper structure tree from the requirements. If I want to use a requirement for a specific purpose for which I have to modify it, then a branch is formed in our system. The user can trace where something was defined or modified in the development and for what purpose. And that lets him reuse exactly the right component.”
This methodical procedure when designing the system is the basis for all of the types of analysis, test and simulations that then follow.
Model-based system development and documentation
An important Systems Engineering question concerns model-based work. Which models are used at what point in development and for what purpose? Are the models linked to one another or not? Are they usable across departments or just in one area?
PTC makes the following assumptions with regard to this question:
- Systems Engineering is primarily used where completely new products are ‘invented’ and developed
- The question of the usage of models is mainly raised where the complexity will be very great, where very specific problems must be solved or where a breakthrough innovation must be realized
If models have not been used at all up to now, it makes little sense to implement these retroactively. Moreover, where work is already being carried out based on models, the customers mostly have the corresponding tools or use specific modeling languages. PTC therefore sees the needs of the customers less in the creation of models, but in their usage, linking and tracking.
Models are particularly important where software plays a major role, for example in the development of controllers or in the modeling of interactions between components, whether these are electronic subsystems, physical components or system sub-assemblies. Here an attempt is often made to generate the needed source code from a corresponding model.
PTC’s goal is a ‘hybrid system’ capable of linking together and using models of widely different origins and types. Wertkin notes that “The key is to remain open! Customers don't expect a one-stop shop for Systems Engineering and that perhaps also applies to PLM.”
PTC views the main tasks as being the following points:
- Documentation of models
- Embedding models in change and configuration management
- Tracking of models with regard to fundamental requirements
- Understanding the effects of requirements changes on models
- Understanding the effects of errors in tests on models
PTC intends to offer a very flexible model for the traceability of creation and change history that will permit the large network of information created within Systems Engineering (and in all its nodes and links) to be traced. From the requirements perspective, all subsequent models should remain traceable, including the analysis and tests carried out on them. In addition, this traceability should be offered at the system level, for subsystems and down to the level of all hardware and software components.
This includes documentation, and therefore implies straightforward access to these complex information networks. Documentation is needed that answers the question as to which model and under which requirements the development of a specific part at a specific time was based – the buzzword here is “baselining”.
With Integrity, PTC also offers the tools for creating and documenting test cases and for the management of test execution. As an example, Andrew Wertkin names ‘hardware in-the-loop testing’. It is possible that no models at all are developed here – the model automatically generates source code and then the software is tested together with the hardware as a complete system in a loop test with an ECU that receives the corresponding signals from a virtual vehicle. This test gives a result, and this result is then returned to the system, for example as a target result to be later achieved in practice with the model. That in its turn can be further followed through and compared to the actual results. When the part is then built into a real vehicle, the results obtained should correspond exactly to those derived from the test.
One of the central differences between conventional mechanical product development and Systems Engineering is the ascendancy of ‘function’ compared to the shape and the geometry. Simulation is the only way of identifying at an early stage whether the development of the components envisaged will actually permit these to work together to meet the requirements defined in the design of the system.
Such simulations are being carried out everywhere today – and in every specialist department. Often, however, these are separate from one another, and not yet in a form that represents the contributions of the individual disciplines to the overall function. Many customers already use Modelica or another high-level modeling language to simulate the functions of a complex system, including the electronics, software components and of course the hardware. But for Andrew Wertkin, the fact is that the industry does not yet have a good way of documenting and handling the results of simulations and tests – and their interrelationships – in an overall system sense.
Why was a simulation run? What were the details of the input? What were the results in the output? If a discrepancy was found between the previous assumptions and the results, how did this occur? And when all the conclusions have been reached, they should be capable of being transferred to future projects. Perhaps this will result in a part of a future FMEA process, and possibly also in a kind of template for a certain part.
PTC does not see itself as having to deliver new tool for simulation, more in documenting and ensuring the traceability of simulations within the framework of the system, its requirements and its interrelations.
Synchronization of the disciplines
The synchronization of the specialist disciplines involved in the development of a system is carried out by assigning requirements to the individual disciplines, by coordinated change management between the disciplines such that, for example, it is possible to trace whether a change in one had effects on another, and by coordinating the tests across all disciplines.
Many tests and analyses carried out at the component level in individual disciplines have an influence on the system. Engineers working on their own part must each have an insight into the other disciplines. And they must simultaneously be capable of using the toolbox specific to their specialty to carry out their own work.
An example: An error has been identified in a test. It could be eliminated on the hardware side, but usually it is much less expensive to solve the problem with the help of the software. PTC focuses on tracing back the corresponding decisions and the underlying events and linking these to the system. Andrew Wertkin remarks “a change must always start with the system in order to permit analysis. This is also the main reason that Systems Engineering is a part of PLM – as long as the decisions remain separate, it is not truly a system.”
PLM and Systems Engineering
By integrating Integrity and Windchill, it is intended to make the best of both architectures available to all customers. Here, both approaches could well complement one another. And PTC can learn from customers who had already carried out this integration themselves before the takeover of MKS. An example of this integration is to be found at Continental, which is one of the biggest customers for both Windchill and Integrity. The goal is to make solutions that work available to customers. Integration should no longer be a project for the customer but rather a solution that is offered to him.
On one hand, software development can, with all its facets, in this way be integrated into the lifecycle of an overall product, smoothing the path towards actually being able to treat all disciplines involved in the development of a system as a whole. On the other hand, PLM itself will profit from several special features originating in software development. An example of this will be making Requirements Management functionality available for Windchill.
The next steps of integration will be determined in conjunction with an advisory group of global PTC customers. These include customers from the aerospace and defense industries, vehicle builders, and manufacturers of high-tech electronics and medical equipment. The next big step, planned for March 2012, is an initial integration of Requirements Engineering with PLM and also making a system BOM available.