The time is ideal to get to grips with systems engineering. SAP recently launched SAP Enterprise Product Development (SAP EPD) Engineering (formerly Intelligent Product Design), a cloud solution that enables deep integration of systems engineering scenarios into PLM and SAP infrastructure, industrializing model-based systems engineering (MBSE). SAP EPD highlights include: Model-based requirements management and systems engineering; functions for workflow-based collaboration; test management for verification and validation; and requirements capture from product operations.
The great advantage of SAP EPD is that interfaces to the SAP world no longer have to be developed and CAD-agnostic work can be performed. Previous initial attempts to move in this direction with freeware products were often abruptly halted by the company’s own IT department. With SAP EPD, it is now possible to move the starting point of SAP PLM forward by means of comprehensive requirements modeling and not to start the connection to SAP objects with SAP Engineering Control Center (ECTR).
The requirements management and systems modeling sub-solution works with SysML. The description language SysML has been standardized for a long time, but it has not yet been possible to speak of broad acceptance. SysML significantly improves cross-discipline communication because systems can be described holistically through models.
E-3 interlocutor Jakob Roehrenbach, Account Executive Digital Supply Chain SAP at Cenit, provides assistance, “The challenge in systems engineering is to make the added values hidden in the system models transparent in the processes.” The methods of systems engineering have been known for a long time and at least fragments of knowledge are available in almost every company, emphasizes Roehrenbach; however, the impetus from outside is necessary when it comes to establishing systems engineering sustainably and comprehensively. And this is precisely the role in which the company sees itself. “As an SAP partner, Cenit has focused on the early phases of the product lifecycle from the very beginning, specifically on the creation of 2D and 3D CAD models and their transfer to further downstream processes, for example in the area of manufacturing. We have also accompanied our customers in the introduction of 3D master concepts. This has resulted in enormous competence in the form of a consulting team and expertise in mapping this in a supply chain model,” says Roehrenbach.
SAP has several E2E approaches in its quiver, including one for the digital supply chain. In the Walldorf-based company’s interpretation, this Design to Operate (D2O) value chain is divided into the phases Design, Plan, Build, Deliver, Operate, whereby the domain of MBSE focuses on design in the D2O cycle, but can also provide value for the other phases. “Until now, the D2O chain often spanned data and departmental silos with system and organizational breaks. MBSE can offer an approach here, both methodologically and in terms of process technology, not only to be able to fall back on a cross-domain product model in the engineering disciplines, but also to hold aspects of the entire PLM cycle centrally and neutrally,” says the second E-3 discussion partner, Christian Markus, SAP Product Lifecycle Management Consultant at the Cenit subsidiary Coristo, and emphasizes, “The special thing about the new SAP EPD solution is its deep integration and thus the access to SAP business objects.”
More than requirements engineering
But what makes MBSE and its claim of consistency in communicating with the various stakeholders different from that of the 3D master? “Basically, they are two parallel approaches that complement each other. The spheres of activity are separate, because the system model includes all development-relevant content and relationships, while the 3D master carries geometry-based information, for example for manufacturing. In particular, requirements and their relationship to changes are mapped without contradiction in the system model via the system diagram,” explains Roehrenbach.
The system model includes so-called satisfied relationships for requirements modeling and verified relationships for test scenarios. However, as Roehrenbach points out, systems engineering should not be understood purely as requirements engineering, i.e. as requirements modeling, although this is of course a very important aspect. What both approaches, MBSE and 3D Master, have in common, he says, is that they both pay attention to the digital twin of a serialized (product) instance. “The MBSE model is very valuable when a virtual prototype is to be created, because all structured interdependencies are available on demand and it is transparent at all times what is being tested,” adds Christian Markus. MBSE models therefore are at the beginning of a digital thread that can lead to the digital twin.
Modeling in the sense of systems engineering is definitely in sight for most companies. They are created or refined on a daily basis using authoring tools such as MCAD or ECAD. However, there are still many gray areas in the area of requirements management, because MS Excel is often used for this. “The important thing at the beginning is to approach systems engineering with a clear will. The as-is analysis is necessary, for example to realize how much of it is already anchored in the company: Who in the company is interested? Who is informed? And who is enthusiastic about MBSE?” asks Markus in his role as change agent.
The well-known systems thinker Russell Ackhoff has dealt intensively with object contexts and agile limits of what is possible: “Problems must not be solved, they must be resolved” is one of his quotes, which can also inspire product development. Together with SAP, Cenit designed the eScooter training plan. “The decision to model an eScooter as a system was motivated by the idea of extending a largely mechanical motor scooter into a lived IoT scenario with electric scooters in free-floating sharing systems,” says Markus. The training plan centers on recuperative braking for electric scooters. Is this worthwhile for such a lightweight vehicle, or isn’t a sailing function better? Feedback from the field (via a service app) revealed that customers wanted recuperation, especially when going downhill, as they were reluctant to run the brakes hot. Previously, this type of recuperation was only discussed from an energy management perspective, but not from a customer experience perspective. In addition, the service app let it be known that the installed disc brakes would not meet the requirements over the entire operating time of the scooter.
“In an intuitive way, you move away from a pipe and toward platform thinking, in which the target group actively helps shape the product design. This is where the system idea reveals itself, namely that the product is not alone in the shop window, but in a context of use and environment,” says Roehrenbach, and Markus adds, “This approach is all about developing much closer to the market. MBSE based on SAP EPD is exactly the tool to practice agile development, because with SAP EPD, it is possible to open up a much larger number of feedback channels for a product.” Most engineers already think intuitively in terms of models, anyway, even though they may use different terminology.
Add Comment