Modern engineering systems are complex and expensive to design, manufacture and service. Guy Johns, Lead Technologist at CFMS, explains why a through-lifecycle approach is needed.
As a discipline, system engineering has evolved over the years to help manage the complexity of modern engineering systems through a set of methodologies and techniques underpinned by analogous software modelling tools. Phrases such as ‘model-based system engineering’ and ‘model-driven design’ are often used to describe the process of modelling artefacts, behaviours and processes, and the cost-benefit of these approaches is well understood, especially within industries such as aerospace and automotive.
That said, the degree of reuse and the ability to capture lessons learned during the initial development stages are neither well documented nor understood. Valuable knowledge is also being lost further down the line during the manufacturing and service stages of the product lifecycle – knowledge that if fed back into system models at the early design stage, could improve processes and cut costs throughout the entire lifecycle. The advent of computing has certainly transformed the engineering industry by allowing companies to draw architectures of a system, but the challenge now is for us to become more adaptive and responsive.
An engineering system can be viewed as a hierarchical model, or we can begin to look at it from a functional perspective of what we want the system to perform and fulfil. The latter approach enables us to abstract out what the product or part is trying to deliver, and that’s where system engineering can truly have an impact. By using a through-lifecycle approach, the finer details organically begin to get filled in as the design of the system matures, and any issues or problems that are encountered can be fed back into the initial stages of the process. Whilst most processes begin with a conceptual design and a rough breakdown of a system, these artefacts aren’t followed through to the latter stages of the lifecycle as the system is refined. This aspect of system engineering isn’t new; however due to a lack of understanding it’s rarely tapped into.
Another missed opportunity is that companies don’t often link system refinement to the testing campaign. This means that if there’s a specific requirement or architecture, some form of implementation is needed before you can begin to think about testing. But what if there was another way of doing things? By taking a through-lifecycle approach, you can start the testing early in the process and try to validate the system architecture with some high level test cases. The benefit here is clear as whilst a system architecture may seem ideal on paper, it may not be viable when manufactured. Having the capacity to think through the functional breakdown and lessons learnt from a mature product out in the market, and then feed that captured knowledge into the initial design, will not only de-risk the effort throughout the process but will improve all future versions of that product.
A real challenge is that this knowledge doesn’t tend to be captured because once a product goes into production and manufacture it’s passed on to a different department and team. Those who design don’t tend to get involved in the latter stages of the lifecycle, and although tacit knowledge is applied, it doesn’t have the same benefit as directly applying captured information and mapping through requirements. Rather than looking at the blank slate of a new product, most companies, especially large ones, have a mature product and are focused on a particular aspect such as manufacturing capacity or streamlining costs. In order to remain competitive, these businesses need to expand organically from where they are, and at CFMS we’re offering our knowledge and expertise on how to do that and where potential pitfalls may lie.
CFMS has been working with companies like Siemens and Rolls-Royce to apply these critical principles and methodologies and develop a through-life system engineering model and framework. Often we find that companies use a product lifecycle management tool but these are rarely more than a function of asset control as they simply record the specific serial number, time, date and place of manufacture of individual parts or products. What these tools don’t do is link back to the design so that if a part goes into service and fails, a timeline can be created that states the design rule that was used, how it led to a specific manufacturing technique, and how the issue arose during deployment. A through-lifecycle approach can reveal that the initial requirement the part was made to was in fact wrong – perhaps it didn’t have right tolerance, for example. This iterative entire-lifecycle approach can be enabled through system engineering.
Building this into an enterprise environment can be difficult, however, as the chain often involves many tools that focus on different aspects of the system, from various vendors that offer no support to each other. One of the reasons we’re passionate about open standards such as the SysML is because they are vendor agnostic, and therefore enable companies to take a more strategic approach of applying the standard to the procured tool of choice.
The SysML open source specification project created the Systems Modeling Language (SysML) dialect of the Unified Modeling Language (UML) for systems engineering applications. Since the SysML dialect profile was named and drafted in 2003, SysML has been adopted by the Object Management Group (OMG) as OMG SysML and has evolved into the de-facto standard for model-based systems engineering (MBSE) applications. Through this standard, tool vendors subscribe to the philosophy of a model is more than an image – it has executable semantics. For example, a designer creating a SysML-compliant model can then generate code from that model or execute it in a specific environment. Constructing a language in order to talk around system engineering and developing a common understanding of diagrams and format that allows us to collaborate and share information in a way that’s semantically understood is a real benefit. What needs to go one step further, however, is the application and embracing of a through-lifecycle approach.
CFMS is trying to bridge the gap between an existing IT infrastructure that’s tied into a company’s processes and procedures, and the opportunities and innovation afforded by through-lifecycle system engineering. Because we have the knowledge and experience of both IT and systems engineering, we can fully understand a company’s domain and offer impartial guidance on how to make improvements to capture, secure and communicate vital information throughout the production process. As a not-for-profit business, we’re able to invite tool vendors and manufacturers to our facilities to analyse and discuss changes that need to be made, and how those changes can be implemented in a managed way that ensures return on investment at every stage of the design and manufacture process.