Everyone talks about "data-centricity," but what does that mean in practical terms. It means that you have to have a well defined ontology that can capture the information needed to describe the architecture or system you work with or want to create. An ontology is simply the taxonomy of entity classes (bins of information) and how those classes are related to each other. In this webinar, we will discuss a relatively new ontology, the Lifecycle Modeling Language (LML). LML provides the basis for Innoslate's database schema. In this webinar, we will discuss each entity class and why it was developed. Dr. Steven Dam, who is the Secretary of the LML Steering Committee, will present the details of the language and how it relates to other ontologies/languages, such as the DoDAF MetaModel 2.0 and SysML. He will also discuss the ways to visualize this information to enhance understanding of the information and how to use that information to make decisions about the architecture or system.

1. Innoslate’s Ontology
AN ONTOLOGY FOR LIFECYCLE DEVELOPMENT AND MANAGEMENT

2. LinkedIn Group:
Innoslate Users
@innoslate
Interact With Us

3. Steven H. Dam, Ph.D., ESEP
President and Founder
steven.dam@specinnovations.com
Expert Systems Engineering
Professionals Certificate
Participated in the development of
C4ISR and the DoDAF
Meet Your Host

4. 1
2
3
4
5
6
What Do We Mean by Ontology?
Lifecycle Modeling Needs for Ontology
LML Ontology
Demonstration: Implementation of LML
Questions and Answers
The Benefits of the LML Ontology
Agenda

5. What Do We Mean by
Ontology?

6. Defining Ontology
• For those that do not know
o Ontology = Taxonomy + relationships among terms and concepts
o Taxonomy = Collection of standardized, defined terms or concepts
• For a database what this provides is the schema for
capturing the data and how the data elements relate to
one another
• Some ontologies are part of a framework (e.g. DM2 for
DoDAF) or language (LML)

7. How Do We Define an Ontology?
• A classic technique is to use Entity-Relationship-Attribute (ERA)
• ERA forms the meta-meta model for the ontology and can be
traced to actual language elements
o An entity is something that can exist by itself and is uniquely identifiable
[Noun]
o A relationship connects entities to each other [Verb]
o An attribute is an inherent characteristic or quality of an entity
 An attribute can be of an entity [Adjective] or relationship [Adverb]

8. Today’s Approach
• Use of the Web Ontology Language (OWL) (from Wikipedia)
o “W3C Web Ontology Language (OWL) is a Semantic Web language designed
to represent rich and complex knowledge about things, groups of things,
and relations between things.” Developed by the OWL Working Group
o Version 1 published in 2009
o Version 2 published in 2012
o “OWL facilitates greater machine interpretability of Web content than that
supported by XML, RDF, and RDF Schema (RDF-S) by providing additional
expressive power along with a formal semantics.”
• What does this do for me?
o Provides naming conventions to enable better communications between
people and between people and computers

9. Lifecycle Modeling Needs for
Ontology

10. The Lifecycle
• Many ways to visualize the
lifecycle, but they all have
essentially the same
phases and steps
• We need to capture
information in each phase
and step to provide
understanding and
documentation for the
design and development of
any product
Architecture
Development
System
Design
Hardware/Software
Acquisition
Integration
and Test
Operational
T&E and
Transition
Future Operations
and Maintenance
Demolition
and Disposal
Program
Management
Current Operations
and Maintenance

11. What Disciplines Do We Need to Support with the
Ontology?
• Disciplines include, but are not limited to:
o Requirements Analysis and Management
o Functional Analysis and Allocation
o Physical Architecture Modeling (from block diagrams to CAD)
o Verification and Validation (including simulation)
o Program Management (all aspects)
• In other words all aspects of systems engineering/program
management
o Both attempt to optimize cost, schedule, and performance – one for the
system, the other for the program

12. LML Ontology

13. Lifecycle Modeling Language (LML)
• LML combines the logical constructs with an ontology to capture
information
o SysML – mainly constructs – limited ontology
o DoDAF Metamodel 2.0 (DM2) ontology only
• LML simplifies both the “constructs” and ontology to make them
more complete, yet easier to use
• Goal: A language that works across the full lifecycle
13

14. LML Ontology Overview
• Taxonomy:
o 12 primary element classes
o Many types of each element class
 Action (types = Function, Activity, Task, etc.)
• Relationships: almost all classes related to each other
and themselves with consistent words
o Asset performs Action/Action performed by Asset
o Hierarchies: decomposed by/decomposes
o Peer-to-Peer: related to/relates
14

15. LML’s Simplified Schema
• Action
• Artifact
• Asset
o Resource
• Characteristic
o Measure
• Connection
o Conduit
o Logical
• Cost
• Decision
• Input/Output
• Location
o Physical, Orbital, Virtual
• Risk
• Statement
o Requirement
• Time
15
Supports capturing information throughout the lifecycle

16. Documentation Entities
Parametric and Program Entities
LML Models
16
Functional
Model
Physical Model
Primary Entities
• Asset/Resource
• Connection
Primary Entities
• Action
• Input/Output
Statement/
Requirements
Cost
Time
Characteristic/
Measure
Location
Artifact
Risk
Decision

17. LML Primary Entities and Relationships for SE Support
17
Artifact decomposed by/
decomposes
Statement
(Requirement)
Characteristic
(Measure)
source of/sourced by
Action
traced to/traced from
Asset
(Resources)
performed by/performs
Input/Output
specified by/specifies
Connection
(Conduit)
transferred by/transfers
connected by/
connects
generated by/
generates
received by/
receives
decomposed by/
decomposes
decomposed by/
decomposes
decomposed by/
decomposes
decomposed by/
decomposes
decomposed by/
decomposes
decomposed by/
decomposes

18. Action Artifact
Asset
(Resource)
Characteristic
(Measure)
Connection
(Conduit,
Logical)
Cost Decision Input/Output
Location
(Orbital,
Physical,
Virtual)
Risk
Statement
(Requirement)
Time
Action
decomposed by*
related to*
references
(consumes)
performed by
(produces)
(seizes)
specified by - incurs
enables
results in
generates
receives
located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Artifact referenced by
decomposed by*
related to*
referenced by
referenced by
specified by
defines protocol for
referenced by
incurs
referenced by
enables
referenced by
results in
referenced by located at
causes
mitigates
referenced by
resolves
referenced by
(satisfies)
source of
traced from
(verifies)
occurs
Asset
(Resource)
(consumed by)
performs
(produced by)
(seized by)
references
decomposed by*
orbited by*
related to*
specified by connected by incurs
enables
made
responds to
results in
- located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Characteristic
(Measure)
specifies
references
specifies
specifies
decomposed by*
related to*
specified by*
specifies
incurs
specifies
enables
results in
specifies
specifies
located at
specifies
causes
mitigates
resolves
specifies
(satisfies)
spacifies
traced from
(verifies)
occurs
specifies
Connection
(Conduit,
Logical)
-
defined protocol by
references
connects to specified by
decomposed by*
joined by*
related to*
incurs
enables
results in
transfers located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Cost incurred by
incurred by
references
incurred by
incurred by
specified by
incurred by
decomposed by*
related to*
enables
incurred by
results in
incurred by located at
causes
incurred by
mitigates
resolves
incurred by
(satisfies)
traced from
(verifies)
occurs
Decision
enabled by
result of
enabled by
references
result of
enabled by
made by
responded by
result of
enabled by
result of
specified by
enabled by
result of
enabled by
incurs
result of
decomposed by*
related to*
enabled by
result of
located at
causes
enabled by
mitigated by
result of
resolves
alternative
enabled by
traced from
result of
date resolved by
decision due
occurs
Input/Output
generated by
received by
references - specified by transferred by incurs
enables
results in
decomposed by*
related to*
located at
causes
mitigates
resolves
(satisfies)
traced from
(verifies)
occurs
Location
(Orbital,
Physical,
Logical)
locates locates locates
locates
specified by
locates locates locates locates
decomposed by*
related to*
locates
mitigates
locates
(satisfies)
traced from
(verifies)
occurs
Risk
caused by
mitigated by
resolved by
caused by
mitigated by
references
resolved by
caused by
mitigated by
resolved by
caused by
mitigated by
resolved by
specified by
caused by
mitigated by
resolved by
caused by
incurs
mitigated by
resolved by
caused by
enables
mitigated by
results in
resolved by
caused by
mitigated by
resolved by
located at
mitigated by
caused by*
decomposed by*
related to*
resolved by*
caused by
mitigated by
resolved by
occurs
mitigated by
Statement
(Requirement)
(satisfied by)
traced to
(verified by)
references
(satisified by)
sourced by
traced to
(verified by)
(satisified by)
traced to
(verified by)
(satisified by)
specified by
traced to
(verified by)
(satisified by)
traced to
(verified by)
incurs
(satisified by)
traced to
(verified by)
alternative of
enables
traced to
results in
(satisified by)
traced to
(verified by)
located at
(satisfied by)
traced to
(verified by)
causes
mitigates
resolves
decomposed by*
traced to*
related to*
occurs
(satisified by)
(verified by)
Time occurred by occurred by occurred by
occurred by
specified by
occurred by occurred by
date resolves
decided by
occurred by
occurred by occurred by
occurred by
mitigates
occurred by
(satisfies)
(verifies)
decomposed by*
related to*
LML Relationships Provide Linkage Needed
Between the Classes
18
• decomposed
by/decomposes
• orbited by/orbits
• related to/relates

19. Diagrams Are Needed for Every Class
• Action Diagram (Mandatory)
• Asset Diagram (Mandatory)
• Spider Diagram (Mandatory)
• Interface Diagrams
o N2 (Assets or Actions)
• Hierarchy Diagrams
o Automatically color coded by class
• Time Diagrams
o Gantt Charts
o Timeline Diagram
• Location Diagrams
o Maps for Earth
o Orbital charts
• Class/Block Definition Diagram
o Data modeling
• Risk Chart
o Standard risk/opportunity chart
• Organization Charts
o Showing lines of communication, as well
as lines of authority
• Pie/Bar/Line Charts
o For cost and performance
• Combined Physical and Functional
Diagram
19

20. Action Diagram
(Mandatory)
20
No constructs – only special types of Actions – ones that enable
the modeling of command and control/ information assurance to
capture the critical decisions in your model
Action A Action B
Action A
Action B
Action C
Condition 1
Condition 2
Action A
Action B
LOOP
Action A
Action C
Range
Range (e.g.)
1 to n (iterate)
Until r < z (loop)
PARALLEL
SEQUENTIAL
SELECTION
SYNC
OR
Action C
(Exit Criteria)
LOOP
Coordinated by Asset C

21. Asset Diagram (mandatory)
21
Block diagram
general form
Block diagram using pictures

22. Spider Diagram (Mandatory for Traceability)
22
Shows entities and
relationships in
visual form

23. LML Translation
• Two types of mapping for tailoring:
o Map names of classes to enable other “schema” models to be
used
o Map symbols used (e.g., change from LML Logic to Electrical
Engineering symbols)
o Enable diagram translations (e.g., Action Diagram to IDEF 0)
23
LML
Symbol
Electrical
Engineering
BPMN …
AND
LML Class DM2 SysML …
Action Activity Activity
Asset Performer Actor

24. SysML Overview
• Nine (9) diagrams used to capture
information
• Extends UML by including behavior,
requirements, and parameters
• Uses XMI for import/export
• Diagrams use symbols and
terminology unfamiliar to many
systems engineers and stakeholders
o Black diamonds to indicate composition
o Sterotypes or metaclasses
o Guillemets (<< >>)
SysML
Diagrams
Behavior Requirement Structure
Activity
Sequence
State Machine
Use Case
Block Definition
Internal Block
Parametric
Package

25. SysML Extensions to LML 1.0 (LML 1.1)
• Added one (1) new class: Equation
• Extended Asset Class: Port
• Added relationship to new class (equation of/equation for, has
variable/variable of)
• Added other relationships:
o For Requirements Diagram: satisfies/satisfied by, verifies/verified by,
copies/copied by, derives/derived by, refines/refined by
o For Use Case Diagram: extend/extended by, include/included by
o For State Machine Diagram: fetches/fetched by, pushes/pushed by

26. SysML Behavior Diagrams in Innoslate®
Sequence Diagram
Use Case Diagram
Activity Diagram State Machine Diagram
SysML
Diagrams
Behavior Requirement Structure

27. SysML Structure Diagrams in Innoslate®
Internal Block Diagram
Package Diagram
Block Definition Diagram
Parametric Diagram
SysML
Diagrams
Behavior Requirement Structure

28. SysML Requirements Diagram in Innoslate®
SysML
Diagrams
Behavior Requirement Structure

29. Mapping LML to DoDAF’s DM2
• Uses labels to identify
DoDAF models
• DoDAF dashboard
shows models and
views by viewpoint
• DM2 Physical
Exchange
Specification (PES)
available as AV-2
• *Innoslate uses labels
to distinguish types
DM2 Schema Element (Conceptual) LML Equivalent
Activity Action
Capability Action with “Capability” type*
Condition Characteristic with “Condition” type*
Information/Data Input/Output
Desired Effect Statement with “Desired Effect” type*
Guidance Statement with “Guidance” type*
Measure Measure
Measure Type Measure types
Location Location
Project Action with “Project” type*
Resource Asset with types for “Materiel,” “Organization,” etc.
Skill Characteristic with “Skill” type
Vision Statement with “Vision” type

30. LML in OWL (Protégé)

31. The Benefits of the LML Ontology

32. Benefits of LML
• Broad (covers the entire lifecycle - technical and programmatic)
• Ontology-based (enables translation from LML to other languages
and back)
• All the capabilities of SysML (with LML v1.1 extensions) and DoDAF
• Simple structure
• Useful for stakeholders across the entire lifecycle

33. What Does LML Do for Us?
• LML provides the fundamental foundation for a tool to support SE
• LML contains the basic technical and programmatic classes
needed for the lifecycle
• LML defines the Action Diagram to enable better definition of
logic as functional requirements
• LML uses Physical Diagram to provide for abstraction, instances,
and clones, thus simplifying physical models
• LML provides the “80% solution”
o It can be extended to meet specific needs (e.g. adding Question and
Answer classes for a survey tool that feeds information into the modeling)
33

34. Demonstration: Implementation of LML using
Innoslate®

35. Questions and Answers:
Enter Your Question in the GoToWebinar Control Panel

36. Call, Email, Tweet, Chat, or Post
10440 Balls Ford Road
Manassas,VA 20109
Blog.Innoslate.com
sales@innoslate.com
support@innoslate.com
571-485-7800
LinkedIn: Innoslate User Group
Twitter: @innoslate
innoslate.com
specinnovations.com
Connect with Us!