Lifecycle Modeling Language

LML: the Lifecycle Modeling Language, in a working tool.

The Lifecycle Modeling Language (LML) is an open modeling language for systems engineering. It describes a system with a small set of entity classes, typed relationships between them and a few simple diagrams. Holarch is built on LML: every requirement, function, component, interface, test and risk in a project is an LML entity.

Start free Read the LML primer

Class and relationship names as Holarch uses them.

What LML is

LML was written to be easy to learn and to cover the whole lifecycle of a system, from the first concept through design, test and operation, including the program work around it. Its specification is published openly. Three ideas carry most of it:

Entities are the things you model, each an instance of a class such as Action or Asset.
Attributes describe an entity, for example the duration of an Action or the units of a Characteristic.
Relationships connect two entities, and each one has a name in both directions. "Capture Image performed by Payload Camera" and "Payload Camera performs Capture Image" are the same link, read from either end.

Relationships can carry attributes too. For example, how many of an Asset an Action occupies is an attribute of the performed by link, not of either entity.

The main classes

LML keeps the number of classes small and uses subclasses and labels for finer distinctions. The classes you meet first:

Main LML classes
Class	What it represents
Action	What the system or the people around it do: functions, activities and tasks
Asset and Resource	Who or what performs Actions: systems, subsystems, people, organizations. A Resource is an Asset that exists in a quantity, such as fuel, power or storage.
Input/Output	Data, material or energy that one Action produces and another receives
Connection and Conduit	Links between Assets. A Conduit is a physical or data link that carries Input/Outputs, such as a cable, bus or radio link.
Statement and Requirement	Needs, goals, assumptions and constraints; a Requirement is a Statement the system must meet
Characteristic and Measure	Properties and parameters; a Measure is tracked against goals, such as a measure of effectiveness or a technical performance measure
Artifact	Documents and other work products, such as specifications and test plans
Risk and Decision	What may go wrong, and the choices the program makes
Cost, Time and Location	Money, dates and milestones, and places (orbital, physical or virtual)

Relationships with inverse names

Every LML relationship is a pair of names, one for each direction. A few that carry most models:

decomposed by / decomposes builds hierarchies of any class: subsystems, sub-functions, child requirements.
performs / performed by allocates Actions to Assets.
generates / generated by and receives / received by connect Actions to Input/Outputs.
connected by / connects to and transfers / transferred by tie Assets, Conduits and the items they carry together.
satisfies / satisfied by and verifies / verified by carry the requirement trace.
mitigates / mitigated by and caused by / causes place Risks in the model.

Because each link is stored once and read from both ends, a requirement can list what satisfies it, and a function can list the requirements it satisfies, without anyone keeping two lists in step.

LML diagrams

LML keeps its diagrams simple and ties each one to the model.

The Action Diagram shows how a parent Action is carried out: its child Actions in order, parallel and alternative paths, loops, and the Input/Outputs passed between steps. It is precise enough to simulate.
The Asset Diagram shows child Assets and the Conduits between them: the physical structure.
The Spider Diagram shows the relationships around an entity as a web, which makes it a natural traceability view.

How Holarch implements LML

Holarch's default schema follows the LML class and relationship names. Every page reads and writes the same entities, so a change in one view shows in all of them.

Default LML schema

Action, Asset, Input/Output, Conduit, Statement, Requirement, Characteristic, Artifact, Risk, Decision and the other classes, with subclasses such as Test Case, Task and Transition under Action. The LML Classes and LML Relationships pages in the Help list them live.

Relationships stored once

Each link has an inverse and is shown from both ends. Holarch offers only the relations the schema allows between two classes, so the model stays valid.

Your own extensions

Add attributes, subclasses, labels, relations and status workflows for one project, and share a schema between projects. A subclass of Action gets action diagrams; a subclass of Requirement gets quality checks.

Action diagrams you can run

Draw the flow with parallel, OR, SYNC and LOOP constructs, Input/Outputs, Resources and performing Assets, then run discrete-event or Monte Carlo simulations of exactly that flow.

Learn more about behavior →

Physical views

Asset, Physical I/O, Interface Control, I-squared and N-squared diagrams draw the structure and interfaces from Assets, Conduits and Input/Outputs.

Learn more about interfaces →

Traceability views

Spider diagrams with impact analysis, traceability matrices on any relationship and an RVTM read the same links.

Learn more about the model →

LML with SysML views

SysML block definition, internal block, parametric, activity, sequence, state machine, use case, requirement and package diagrams are views of the same LML entities.
A block is an Asset, a connector is a Conduit, and a constraint block is an Equation.
Edit a block on a SysML diagram and it changes on the Asset Diagram too. See SysML diagrams in Holarch.

Where to read more

The Model and Database reference covers entities, classes, attributes and relationships.
Schema and Extensions covers changing the schema for a project.
Action Diagrams covers the flow, its constructs and how it maps to LML.
New to the subject? Start with what MBSE is.