WHITE PAPER Breaking Down the Silos How Systems Architecture Enables Interdisciplinary Collaboration
Michael Pfenning, Senior Product Manager, Aras 2 Breaking Down the Silos: How Systems Architecture Enables Interdisciplinary Collaboration
With the ever-increasing complexities of today’s systems, organizations struggle to address the interdisciplinary collaboration across a product’s entire lifecycle. This is because the collaboration must extend beyond the traditional BOM-driven and mechanically- oriented physical structures. It must embrace functional aspects of the system that are allocated and cross-optimized across multiple disciplines whose data models today reside in individual silos.
Systems Engineering has a central role in enabling such interdisciplinary collaboration because it is the only authoritative source of the system’s design intent. The other disciplines rely on that source to implement or to verify that design intent. Systems Engineering creates a formal system definition during the design phase to formalize early decisions. It does that by documenting the system’s requirements, behaviors, and structures. Unfortunately, Systems Engineering today, in most cases, also exists in its own data silo and therefore design-intent driven interdisciplinary collaboration remains unresolved.
Figure 1: MBSE systems model sections in SysML
Source: http://www.omgsysml.org/what-is-sysml.htm Breaking Down the Silos: How Systems Architecture Enables Interdisciplinary Collaboration 3
From Documents to Models and Data What systems engineers did over decades in the form of documents now needs to be done in a more formal way. Systems engineers have been accustomed to working with Systems Engineering Management Plans, Design Specifications, Concepts of Operation, Functional Flow Block Diagrams (FFBD), and of course spreadsheets, a lot of them—documents a human being may understand but a computer does not.
This is where formal models are stepping in. Models that can be interpreted by an algorithm and also easily understood by users via their graphical notation. Model-Based Systems Engineering (MBSE) aims to do exactly that. Allowing systems engineers to capture information efficiently in a graphical manner and formalizing that information in a way a computer understands it—to automate, to reuse, and to trace.
There is No Green Field Anymore The tools and methods of today’s Systems Engineering practices are not completely new. Because of that, a lot of Systems Engineering data already lives somewhere—in some organizational unit, in some tool, in some database such as requirements documents, behavioral simulation models, parameters in CAD designs. In other words, the information is scattered among many legacy documents and tool specific data silos. Recreating all that data in yet another “MBSE silo” is inefficient and doomed to failure. Migrating existing tools and databases to one big monolithic data management solution is expensive and fails eight out of ten times due to the complex nature of those migration projects1.
The only way to achieve the MBSE goal of becoming a common reference point over the whole of a system’s lifecycle is to connect structures in the MBSE authored system model to information management solutions that already contain some of the related information. Unfortunately, most legacy PLM software in use today are architected around mechanical BOM-driven data structures and are therefore not extendable to representing MBSE data. Therefore, modern PLM architectures like the Aras Innovator Platform are required. The Aras Platform is architected to model new data structures (like MBSE) along the existing data structures (like mechanical) and the relationships between them. The Platform allows you to include these newly added MBSE data structures to the product’s Digital Thread. And Digital Thread is key to traceability between the elements of various design representations, even if the underlying data is spread among different data containers. 4 Breaking Down the Silos: How Systems Architecture Enables Interdisciplinary Collaboration
A A D S
R E E E E
D S S S S
S S S S S D D S T T T T T T
Figure 2: The Aras Platform normalizes tool-specific data into tool-agnostic structures
PLM-enabled traceability across a variety of databases is called an overlay approach with database federation. Instead of ripping and replacing existing legacy data management solutions, leading to never ending migration projects, the missing gaps in an IT architecture are filled with a flexible layer that can connect to the existing environment. In Figure 2, a generalized engineering IT environment is shown—the existing domains are on the discipline level, the Aras Platform sits in the interdisciplinary level and connects to the discipline- specific tools and manages the links in between them. Each of the domains may have its own data management tool or it may be directly integrated with the so-called interdisciplinary backbone. MBSE is shown as an additional specialized engineering domain that formalizes the system model whereas the backbone only captures the most relevant artifacts as the Systems Architecture Model (SAM).
System models are very complex and contain a lot of information that is of interest only to systems engineers. Only certain portions of the system models need to be exchanged with the other engineers and consequently only those portions need to be exposed to the Aras Platform. In the case of interdisciplinary collaboration, that portion is the system architecture. That is because the architecture model is the key common reference point throughout the system’s lifecycle and therefore it is key to interdisciplinary collaboration. Breaking Down the Silos: How Systems Architecture Enables Interdisciplinary Collaboration 5
S stem rchitect re S stem o el S o el S Figure 3: Aras user-customizable Anchor Elements
The process of mapping MBSE tool-specific data structures to the Aras Platform is based on a unique concept of anchor elements—selected items in the MBSE system model that systems engineers expose to the rest of the enterprise. With the anchor elements approach, you may define your own set of anchor elements as there is no such thing as an out-of- the-box Digital Thread. To help with this process, Aras developed a Systems Architecture application for defining and navigating a tool-agnostic architecture model of a system within its PLM Platform.
Aras’ Systems Architecture (SA) application² comes with a predefined set of architecture model elements that are a good starting point for establishing your Digital Thread. These are: requirements, functions, system elements, parts, and test cases covering the whole of the systems engineering v-model.
VERIFICATION & VALIDATION
SYSTEMS ACCEPTANCE MANUFACTURING MAINTENANCE REQUIREMENTS TESTS
S S S S SIMULATION TEST CASES FUNCTIONS SYSTEMS SYSTEMS ARCHITECTURE TESTING
REQUIREMENTS SYSTEM ELEMENTS
Figure 4: V-Model
SERVICES
MECHANICAL PARTS ELECTRONIC
SOFTWARE 6 Breaking Down the Silos: How Systems Architecture Enables Interdisciplinary Collaboration
Openness and Flexibility is Key The most important characteristic of a systems engineer is the ability to think across all disciplines and to collaborate with engineers in all disciplines. To make interdisciplinary collaboration a reality—with the architecture model at its center—software you are using needs to have an open and flexible access to all relevant data including federation with multiple external data containers. The unique open architecture of the Aras Platform connects to authoring tools and enterprise software, allowing distributed teams to collaborate across the entire product lifecycle. The openness of the environment supports data sharing across the organization, providing the critical capabilities necessary for digital transformation efforts.
MBSE and PLM—The Best of Two Worlds System modeling tools are usually very strong in visualization and semantic-rich formal modeling, but they lack the necessary data management capabilities that PLM software provides. By expressing a system architecture model in the Aras Platform, it instantly becomes compatible with the Platform’s standard services such as revision control, configuration management, permission modeling, work flows, change control, etc. This allows systems engineers to use the MBSE tools in an unconstrained creative way while having parts of the system model exposed to the enterprise (systems architecture) under a formal and uniform PLM process control. That control is key to well-disciplined interdisciplinary collaboration—exactly how those interdisciplinary processes need to be set up is up to each individual organization. The key building blocks for data management are in the Aras Platform—how you want to use them is your choice.
To learn more about Aras Systems Architecture visit: aras.com/en/capabilities/systems-architecture.
1 According to a Gartner survey from 2017 83% of migration projects fail or succeed their budget and schedule. 2 In addition, other Aras applications (e.g. Requirements Engineering (RE)) may need to be installed as well. Aras provides a resilient platform for digital industrial applications. Only Aras offers open, low-code technology that enables the rapid delivery of flexible, upgradeable solutions for the engineering, manufacturing, and maintenance of complex products. Aras’ platform and product lifecycle management applications connect users in all disciplines and functions to critical product data and processes across the lifecycle and throughout the extended supply chain. Headquartered in Andover, MA with major offices throughout the world, Aras supports more than 350 global multinational customers and over 250,000 users. The Aras Innovator platform is freely downloadable. All applications are available at a single subscription rate, which includes all upgrades performed by Aras. Aras customers include Airbus, Audi, Denso, GE, GM, Honda, Kawasaki, Microsoft, and Nissan. www.aras.com
© 2020 Aras. All rights reserved. This document is for informational purposes only. Aras and Aras Innovator are either registered trademarks or trademarks of Aras Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. REQ-1525-2009