Start integrated and stay integrated with MBSE
The failure to communicate is the root cause of many engineering failures and can have catastrophic consequences in late stages of development. As product complexity increases it requires more engineers dealing with mind-boggling complexity that are required to do more with greater constraints and less time, deal with very demanding customers and Interact with more and more people. The result is you no longer have an engineering problem, you have a communication and information management problem. Solving this problem is a major goal of model-based systems engineering (MBSE) because each discipline is speaking a different language: mathematics, electronics, software, construction, etc.
With today’s products, an increasing combination of mechanics, electronics and software that include complex mechanical systems, hundreds of electronic control units (ECUs) and millions of lines of code exponentially increases the potential for error. Integrating these systems early on prevents costly integration delays in the latter half of development because the systems are not fully designed, and changes are much easier to make. Doing this in a continuous manner is even better, such that one engineer can understand where and how their system interfaces with another of even the entire system of systems.
Communicate, communicate, communicate
As an example of how not communicating early and often can impact the overall design’s functionality, take a look at the figure 1. It shows an ECU with a zinc back plate mounted onto a steel crossmember without and separation or barrier. This resulted in galvanic corrosion, eventually destroying the ECU and causing causing the fuel pump to shut down. The lack of communication and understanding of the greater system resulted in a recall affecting 86,000 vehicles at a cost of about $8.6 million.
The ability to see these types of cross-domain interactions requires a high-level and cross-domain product architecture. And it needs to be captured before starting product development to detect and prevent these problems during costly integration phases. Like a building’s architecture, the product architecture is the blueprint for the various downstream development disciplines describing WHAT needs to be done and how well to do it (the means of communicating). But creating that blueprint to guide development requires the relevant requirements from the customer and any other stakeholders – how efficient does the building need to be? Is the building location prone to seismic activity? What materials are available for construction? Many product development organizations today don’t have a product architecture (or integrated product architecture) leading to costly product recalls, as described above, in their products as complexity increases and often repeating the same mistakes from lack of insight.
Include the entire organization
Further investigation into our recall shows this wasn’t an engineering mistake but rather a purchasing error. Purchasing decided to change suppliers in an attempt to reduce costs and neglected to communicate material and other requirements to the supplier, thus a new, less expensive zinc back-plated ECU went smoothly into the manufacturing chain without knowing it created a galvanic corrosion problem until fuel pumps stopped working months later, meaning that nearly everyone in an organization that directly or indirectly affect the product need to be thinking cross-domain systems (even purchasing). An important aspect of an MBSE solution is that it not only covers engineering and development disciplines, but also purchasing departments, marketing and other business activities. Having up to date information and insight, regardless of activity can save time and headaches.
Since it’s impossible to predict/consider everything that might happen during development, be it late deliveries, unexpected changes to customer requirements or unavailable resource, systems engineers need to be agile. Switching gears and performing the important role of executing the daily development process to work alternatives and plan adjustments is critical to development surprises. Arbitrating how to handle the multiple cross-domain impacts of the unexpected is a real hurdle without the right tools. This is much like a building architect who creates the original set of plans for the construction crews but then shifts to spending time at the construction site to deal with surprises. If the architect isn’t there virtually or otherwise, the trades experts make their decisions in isolation without understanding the consequences, potentially resulting in costly setbacks.
It’s not just the aerospace or automotive industries that have this problem; almost all multidomain industries pad their schedules for system integration risk/failure, and no one is ever surprised by a half program schedule padding. Implementing MBSE to manage the interconnected systems of systems, both of the product and the business, reclaims this lost time from development schedules. It allows the larger companies with decades of experience in mechanical design to match the development speed of smaller and more agile competition from tech. and more software focused industries in the transition to highly integrated vehicles.
Siemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering, manufacturing and electronics design meet tomorrow.
Xcelerator, the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software, helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new insights, opportunities and levels of automation to drive innovation.
For more information on Siemens Digital Industries Software products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook and Instagram.
Siemens Digital Industries Software – Where today meets tomorrow
