Most systems engineers are familiar with modeling languages such as Integrated Definition (IDEF), Business Process Model and Notation (BPMN), Unified Modeling Language (UML), Systems Modeling Language (SysML), and Lifecycle Modeling Language (LML). These languages describe how to draw diagrams for systems engineering. However, their ontologies are limited in the ability to express the wide range of entities, relationships, and attributes needed in today’s systems engineering environment.
IDEF was created for systems and software engineers. It consists of a family of languages covering functional modeling to data, simulation, object-oriented analysis/design, and knowledge acquisition. The most used of the IDEF languages is IDEF, a functional modeling language.
Business Process Management Initiative created BPMN for business process management. It is a graphical representation of the business process. Object Management Group currently maintains BPMN for the community.
The perception in the community that software is “the problem” created a need for an “object-oriented” approach to software development and then systems engineering. In the past decade, the UML and now the SysML profile have dominated the discussion. SysML was designed to relate systems thinking to software development, thus improving communication between systems engineers (SE) and software developers. However, the software is not the problem. Usually, the problem has been poor requirements analysis, lack of V&V planning in the design phase, and monitoring by systems engineering throughout the lifecycle.
Then the DoDAF Meta Model 2.0 (DM2) was developed to “increase utility and effectiveness of architectures via a rigorous data model.” The DM2 is designed to support the DoD’s framework. It uses DoD-specific concepts and has no recommended diagrams as part of specification. Dr. Steven Dam’s book DoDAF 2.0: A Guide to Applying System Engineering to Develop Integrated, Executable Architectures is a great source to learn more about DM2.
The AP233 was created for the systems engineering community as a Standard for Exchange of Product information (STEP) data exchange. Its implementation in current systems engineering tools has been very limited.
The Lifecycle Modeling Language was developed to provide systems engineers with a less complex language that worked for all stakeholders. LML has 12 primary entity classes. Some of the entity classes include Action, Asset, Cost, Decision, Risk, etc. Note that these can capture both classical systems engineering and program management information. Each entity can have different types. For example, an Action entity can be of a type: Function, Activity, or Task. This way we can distinguish between Functions and Tasks, without having to have an entirely new set of attributes and relationships, which provides confusion as uses of those languages always wonder “what bin do I put the information in? Is it a Function or Activity or Task?”
Almost all the entities in LML relate to each other and themselves with consistent wording. For example:
By using the same verbs for the relationships in each direction, we immediately know what the inverse relationship will be. We also know that all parent and child relationships are the same.
LML was developed to support all the domains where systems engineering and program management are performed, including the enterprise architecture area. The chart below shows how:
| Systems Engineering | Architecture | Program Management | Lifecycle Modeling Language |
| Cost | (How much) | Cost | Cost |
| Schedule | When | Schedule | Time/Action |
| Performance | |||
| Form | Who | Organization | Asset |
| What | Resource | Resource | |
| Where | Location | Location | |
| Why | Goal, Objectives, Decisions | Decision & Statement / Requirement | |
| Function | How | Task | Action |
| Metric(Fit) | Metric | Characteristic / Measure | |
| Interface | Connection (Conduit) & Input / Output | ||
| Risk | Risk | Risk | |
| Artifact | Artifact |
The figure below shows the different models and the mapping of the entities to those models. Documentation Entities (Artifact, Statement/Requirement) provide a means to capture the existing documentation and break it up into parts that can be traced to other models and entities. For example, a Requirement can be traced to an Action or Asset using the traced to relationship.
The functional and physical model provides a common way to separate the functionality from the physicality – a major goal of systems engineering, as that allows us to create a function model that can be implemented in many ways.
The Parametric and Program entities capture the attributes of the system (characteristics and measures), along with cost, schedule, risk, and decision information.
All these entities have relationships with each other for information traceability.
The complexity of the relationships (as represented by everything being connected to everything) is simpler than that provided in most schemas. Attributes on relationships also are allowed, which enables the complexity but abstracts it in a way to make it seem easier to a user.
Every entity should have one or more diagrams associated with it. LML mandates only the three types for Action (which includes Input/Output entities as well as Actions and their sequencing), Asset (which shows how Assets are connected through Conduits – a subclass of Connection), and Spider (which can show any entity and associated relationships between the entities). The Action Diagram provides the primary way to visualize the Functional Model, while the Asset Diagram visualizes the Physical Model. The specification provides the complete list of suggested diagrams.
There are a plethora of languages for systems engineers to use. SPEC Innovations recommends The Lifecycle Modeling Language because LML meets these 5 goals:
The systems engineering community is offered many different modeling language standards. You should choose the standard that meets your goals. If you are working with the DoD Architecture Framework, then you should choose to use the DM2 standard. Many assume SysML makes the best model-based systems engineering since it has been around the longest. However, LML is the best language for all stakeholders, because the language works for systems engineers, architecture developers, and program managers.
Looking for a powerful tool to visualize and analyze your systems engineering data? Start making data-driven decisions with Innoslate. Sign up now!