Why LML?

We live in a time period where Information Technology grows on a daily basis. Budgets and schedules have become more constrained. Systems have become even more complex. Complexity is a major issue for systems engineers, program managers, and business process engineers. We are approaching an even more challenging future. System designs need to deal with this complexity.

Systems Engineers need to use languages that are:

1. Easy to understand
2. Easy to extend
3. Supporting both functional and object-oriented approaches
4. Useful for both Systems Engineers and the other stakeholders across the system lifecycle
5. Supporting system development processes from concept to disposal.

The goal of Life Cycle Modeling Language (LML) is to meet all five of those needs in one modeling language in a data-driven approach. LML forms the basis for Data-Driven Systems Engineering (DDSE) by meeting these goals and moving us beyond Model-Based Systems Engineering (MBSE). Let’s explore each goal in more detail.

1) Easy to Understand

If complexity is a major issue for systems engineers, then why do current systems engineering languages tend to add complexity to already complex problems? These current systems engineering languages make it more difficult to communicate the underlying issues and develop effective solutions.

The first priority in setting goals for LML was to create a simpler language that could be easy to understand through all the stages of the lifecycle.

The LML authors wanted to define a common, simpler language that can be used for information capture, as well as modeling and simulation, of all stages of the lifecycle. LML provides an easy to understand ontology, yet robust enough to use clear diagrams to express the system design information.

2) Easy to Extend

A benefit to LML that was lacking in previous Systems Engineering languages is its ability to extend.

Since, LML is designed to be a simple language it becomes more extensible to the entire set of lifecycle stakeholders. LML supports the needs of a specific customer, organization, and/or project in any lifecycle discipline.

All lifecycle disciplines can use LML, including systems and design engineering, program management, and many more. LML also allows you to test and evaluate data into a single framework. As we all know, communication is critical for systems engineers. LML allows for easy communication across many different disciplines.

If you would like to know more about the process for extension submission, then visit lifecyclemodeling.org.

3) Supporting Both Functional and Object-Oriented Approaches

A Systems Engineering language that supports both functional and object-oriented approaches is something Systems Engineers have needed for a long time. LML has an elements correspondence that allows for both functional and object-oriented approaches to work within the same design.

LML can translate to object languages, such as UML/SysML (as shown in Version 1.1 of the LML specification). The LML formulation uses the (ERA) meta-meta model; entity, relationship, and attribute. These language elements correspond to object language elements; classes (entity), relations (relationship), and properties (attribute). Attributes can be on both the classes and relationships creating a complete language with nouns (classes), verbs (relationships), adjectives (attributes on classes), and adverbs (attributes on relationships).

4) Useful for Both Systems Engineers and the Other Stakeholders across the System Lifecycle

Current Systems Engineering languages do not allow for easy interaction with systems engineers and other critical groups (program managers, enterprise architects, V&V specialists, etc.) in all stages of the system lifecycle. The need for this interaction has been growing with the changes to information technology.

The Program Manager is primarily concerned with cost, schedule, tasks, resources, and risks. Enterprise architects capture their information using the “5WH” model (What, Why, When, Where, Who, and How). The systems engineer’s goal is to optimize cost, schedule, and performance (form, fit, function). LML overlaps the Program Manager’s, the Enterprise Architect’s, and the Systems Engineer’s concerns and goals and incorporates them into one comprehensive set of design elements.

The table below shows you how LML does just this.

5) Supporting System Development Processes from Concept to Disposal.

The final goal LML accomplishes is the ability to support system development processes from the concept development phase to the final disposal of the systems. LML gives you the ability to complete a full lifecycle across many different disciplines and stakeholders. Through accomplishing the first four goals, LML supports the full lifecycle. Without the ability to support function and object approaches, interact with systems engineer and critical groups through the lifecycle, and easy to understand/extend LML would not be able to completely support the lifecycle.

Today’s technology is moving so fast, but sometimes our methods do not move with it. LML seeks to meet the needs of today’s Systems Engineers. Current Systems Engineers require a language that allows them to communicate with other lifecycle stakeholders, while completing a full lifecycle. LML does simply just that.

Many MBSE tools have made their languages privatized. LML was designed to be an open standard, for anyone to use. Though LML has not become a common Systems Engineering language yet, hopefully more Systems Engineers will realize the benefit to using LML.