obse - ontology based system engineering

Ontology Based Systems Engineering

Nordic Systems Engineering Tour – April, 2013

www.reusecompany.com

http://www.reusecompany.com/

2 April 15th,16th, 17th 2013 Nordic Systems Engineering Tour


Juan Llorens

CTO in The Reuse Company

Professor at Carlos III University

Technical Director of INCOSE’s Spanish Chapter

[email protected]



Fundamentals of

Ontology Based Systems Engineering (OBSE)



Need of knowledge for better Systems Engineering

The “smarter” we want systems engineering to be, the more dependent on

“semantic” knowledge shall it be.

For Requirements Management and Engineering

Writing Management Engineering

0% 25% 50% 75% 100%

Semantics





“semantic” knowledge shall it be. Challenges for Requirements Quality Mgmt.

(source: Gauthier Fanmuy - the RAMP project: - AFIS)





“semantic” knowledge shall it be.

0% 25% 50% 75% 100%

Semantics

Knowledge must be represented within a knowledge structure (KOS)

from internal representations to glossaries, to …., to ontologies)

The selection of the knowledge structure allows different possibilities to the

organization



Knowledge Organization in Systems Engineering

The concept of System Knowledge Repository (SKR) is born

(source: INCOSE –UK chapter)

SKR




System Knowledge Repository (SKR)

Allows representing, storing, managing and

retrieving

Relevant knowledge around the System

and its domain (including the SE Process)

Digital content (Assets) regarding a

particular System

The SKR is formed by

SKB – System Knowledge Base

SAS – System Assets Store




SKB

Supports the complete system knowledge-

base for the application of semantic services

around the system life cycle (Including SE).

SAS

Manages a formal representation of the

System Assets: Requirements, Models, etc.

Is the base for offering services around these

assets

Reuse

Traceability

MDE, TDD, etc.




System of Systems

Sub-System Knowledge Base (SSKB)





…




System of Systems





System Assets Store (SAS)

Assets (SAS)



(source: James Martin)


A reusable implementation



Controlled vocabulary: valid terms, forbidden terms… Optionally can include a Glossary (description for every term).

Thesaurus: Relationships between terms: hierarchies, associations, synonyms…

Light Ontology: syntactic and Semantic groupings for Terms and Actions (verbs). Domain terms and verbs.

Patterns and Representation Schemas for Identifying (patterns) and representing (Schemas) the semantics of knowledge in digital artifacts.

System Knowledge Base: Ontology

What is an ontology for TRC?



Controlled Vocabulary

Needed for standardizing and normalizing the terminology used in the custom

application. The input information must/should match the controlled vocabulary.

Using a glossary with different categories of terms, the ontology may store:

Business related Terms : those terms central to the business area to be treated

General Language Terms:

Syntactically relevant phrases: Adverbs, Adjectives, etc.

Invalid terms: those terms that could be of no relevance.

Engine

based

vehicles

Vehicles

Emissions

control

Pollution

emissions

Legislation

Environment

al impact

evaluation

Noise

and

vibration

s

Air

conditioning

Air flow

Conduct

Diesel

engines

Gas Engines

Electric Engines

Engines

Hybrid engines

Pressure

loss

Vehicle

structure

Door

structure

Window Security

Safety and

health

Hvac system

Doors



Controlled Vocabulary : Example for Requirements Authoring (RA)

UR044 : The Rad8 shall be able to identify hits at a minimum rate of 10 units per second

shall

identify

hit

unit

minimum

second

…..

The

to

at

Rad8



Thesaurus

A Thesaurus stores relational information regarding the terms in the glossary.

Used For:

Retrieval purposes

Representation normalization purposes

Suggestion purposes (Decision support)

“solution specific” purposes

Stakeholder

User

Administrator

Standard user

Customer

Administrator

Admin

Engine

based

vehicles

Vehicles

Emissions

control

Pollution

emissions

Legislation

Environmental

impact

evaluation

Noise and

vibrations

Air

conditioning

Air flow

Conduct

Diesel

engines

Gas Engines

Electric Engines

Engines

Hybrid engines

Pressure loss

Vehicle

structure

Door

structure

Window

Security

Safety and

health

Hvac system

Doors



Thesaurus : Example for RA

UR044 : The Rad8 shall be able to identify hits at a minimum rate of 10 units per second

Rad8

identify

second

…..

Rad8 PTT Radar Sonar =

Distinguish =

UR03442 : The Radar shall be able to distinguish hits at a minimum rate of 10 elements per s

s =



Light Ontology

Syntactic Information (Term Tag)

For NLP purposes

For specific Pattern Restrictions

Semantic Information

For Retrieval purposes

For specific Pattern Restrictions

Idiomatic Information

For NLP purposes

Artifact Type Information

For Retrieval Filtering purposes



VERBS

NOUNS

Syntactic Information : Application to Requirements

Authoring

UR044 : The Radar shall be able to detect hits at a minimum rate of 10 units per second

Doppler radar

identify

Radar Sonar

Detect

UR563 : The Doppler Radar shall be able to Identify hits at a minimum rate of 10 units per

second

PREPOSITIONS OF A



<DETECT>

Verb Semantic

<DETECTION DEVICE>

Term Semantic

Semantic Information : Application to Requirements

Authoring

UR044 : The Radar shall be able to detect hits at a minimum rate of 10 units per second

Doppler radar

identify

Radar Sonar

Detect Recognize

UR563 : The Doppler Radar shall be able to Identify hits at a minimum rate of 10 units per

second

DOMAIN TERMS

Doppler radar Radar

DOMAIN VERBS

identify



Patterns

Sequential restrictions structure with place-holders for the specific terms

and values that constitute a particular knowledge statement, where the

restrictions can be grammatical, semantic, or even both, as well as other

patterns.

A pattern encapsulates the rules for writing and validating a knowledge

statement of a particular kind.



Patterns : Sequence of Restrictions (in place holders)

Restrictions:

Term

Syntax

Semantic

Syntax + Semantic

NL Text:

Term1 Term2 Term3 Term4 Term5 Term6

Restriction 1 Restriction 2 Restriction 3 Restriction 4 Restriction 5 Restriction 6



Patterns: Application to Requirements Authoring

UR044 : The Radar shall identify hits at a minimum rate of 10 units per second

Detection Pattern 1

The <OBJECT

DETECTION> Shall <DETECT> <ITEMS> <MINIMUM> At Rate of

<RATE

VALUE> [NUMBER ]



Representation Schemas

Create a formal representation of the knowledge Statements based on the

Pattern information

<<Semantic of Term2>>

Term2

Term1 Term3

<<My Semantic>>

Term3 Term6

NL Text:

Term1 Term2 Term3 Term4 Term5 Term6

Restriction 1 Restriction 2 Restriction 3 Restriction 4 Restriction 5 Restriction 6



Representation Schemas : Application to Requirements

Authoring

<<Detect>>

Identify

Radar Hits

<<Minimum

Value>>

Hits 10 Units per Second


The <OBJECT

DETECTION> Shall <DETECT> <ITEMS> <MINIMUM> At Rate of

<RATE

VALUE> [NUMBER ]



Representation Schemas


UR852: Targets shall be detected by the Electromagnetic sensor at a frequency not lower

than 10 units per second

UR044

UR852

Synonyms

Electromagnetic sensor

Electromagnetic device

System

Lidar

…

Synonyms

Target

Echo

…

Semantic equivalences:

Identifies

Find

Distinguish

Discover

…

<<Detect>>

Radar Hits

10

Units per Second

<<Minimum Value>>

System

Knowledge

Repository



Applications of OBSE to Requirements Quality Mgmt.

Application 1

Use of Ontologies for CCC



Application 1 - Use of Ontologies for CCC metrics

Correctness

Consistency

Completeness

Several possible metrics

Consistency

(Redundant

requirements)

Consistency

(Inconsistent

units)

Completeness

(Missing

requirements)

Correctness

(Individual

requirement

metrics)

Completeness

(Missing links)



Correctness : Individual requirements metrics

Size

Readability

Conditional vs. imperative sentences

Active vs. passive voice

Optional sentences

Ambiguous sentences

Subjective sentences

Implicit sentences

Abuse of connectors

Negations

Speculative sentences

Use of false friends

Design terms

Flow terms

Number of domain nouns and verbs

Acronyms

Hierarchical levels

Volatility

Number of dependences

Is a Standard Requirement



Individual requirements metrics for correctness 1/3

Size: expressed in paragraphs, chars, nouns or verbs. Long requirements will be difficult to

understand

Readability: number of letters between punctuation marks and some other formulas

than indicate whether the requirement will be easy to read. Ease to read requirements

generates less problems all over the project

Conditional sentences vs. imperative sentences: avoid “would” and use “Shall”,

“should” and “will” in the right way

Active vs. passive voice: avoid using passive voice to increase the readability of the

requirement

Optional sentences: ”maybe”… Optional requirements must be stated by an attribute,

never in the body of the requirement

Ambiguous sentences: ”fast”, “user-friendly”… What do the analyst, the coder and the

customer understand by the same ambiguous sentence




Subjective sentences: ”in my opinion”, “I think that”… Don’t show your ideas, but what the

system should do

Implicit sentences: ”It must be provided by them”… Too many pronouns make your

requirements difficult to understand

Abuse of connectors: “and”, “or”… Many times connectors reveal different needs enclosed

within the same requirement, loosing the atomic characteristic

False friends: customized according to “native language” of your project

Negations: “no”, “never”… Two or more negations in the same sentence make it difficult to

understand

Speculative sentences: ”usually”, “almost”, “always”… Make the requirement imprecise

Design terms: ”loop”, “hash”… Remember: avoid How, concentrate in What

Flow terms: ”while”, “if”, “else”… Remember: avoid How, concentrate in What




Number of domain nouns and verbs: domain terms and verbs should be involved into

the requirement specification, nevertheless, too many different terms in the same

requirement many times means multiple needs

Acronyms: avoid those that don’t belong to the domain representation

Hierarchical levels: don’t complicate your specification with too many indentation

levels

Volatility: if a requirement suffers many changes, you must be very careful with it

Number of dependences: the same if your requirement is the source of too many

dependences

Standard Requirement: The requirement can be matched with one or many of the

requirement templates defined by the organization.



Correctness

Negations

Conditional Sentences

Design Terms

Connectors

etc.


Thesaurus

Light Ontology

Patterns and Representation Schemas

Acronyms

Standard Requirement



Metrics for consistency

Redundant requirements: Several requirements expressing the same need at

the same level of abstraction.

Inconsistent units: Different requirements in the same module/block/project

uses different metric units.

Value restrictions: Different requirements present value restrictions that are

not compatible.



Consistency

Redundant requirements


Thesaurus

Light Ontology


Inconsistent Units

Value restrictions



Metrics for completeness

Missing requirements: Lacks the existence of requirements expressing the

same need at the different level of abstraction in different modules/blocks of the

same project.

Missing Links Lacks the existence of links between requirements expressing

the same need at the different level of abstraction in different modules/blocks of

the same project.



Completeness

Missing Requirements


Thesaurus

Light Ontology


Missing Links



Completeness



Applications of OBSE to Requirements Quality

Application 2

Smart Requirements Authoring



Application 2 – Smart Requirements Authoring

Requirements Authoring :

V&V&V on the fly

A well written set of requirements would reduce the reviewing cost.

If requirements arrive to the Quality Management group with low quality,

the quality assessments becomes an expensive task

Activities assessing requirements quality during authoring time

will reduce quality management groups workload

will reduce even more the effort for reviewing.



V&V&V on the fly



V&V&V on the fly

Requirement

Validated

Verified

Verified

Organization

System

Stakeholder

Match the Requirements against the Organization’s quality standards

(boilerplates, terminology, semantics, etc.)



Requirements Authoring tools

Properties of a Requirements Authoring tool

It must calculate the same metrics that the Requirements Quality Analyzer but

on the fly

The author must get information about the quality of the written

requirements before they are saved on the Requirements Management

Tool

It must be integrated with the Requirements Management Tool

It must be simple and with a non aggressive GUI.

It must advice, as much as possible about the CCC metrics

Correctness

Completeness

Consistency



Demo Video



Requirements Authoring Tool – RAT V4.0 Simple



Requirements Authoring Tool – RAT V4 Complete



Conclusions

The challenges in SE are growing

Knowledge Management is a present/future key factor in SE for helping to

handle with growing complexity

Ontologies are promising enablers

The application of Ontologies in Requirements Quality Management is a

successful application at present time

Pilot projects show viability of the approach.

http://www.reusecompany.com

[email protected]

Margarita Salas, 16 2nd Floor

Innovation Center

LEGATEC Technology Park

28919 Leganés – Madrid

SPAIN – EU

Tel: (+34) 91 146 00 30

Fax: (+34) 91 680 98 26

mailto:[email protected]

