OBSE - Ontology Based System Engineering

Ontology Based Systems Engineering

Nordic Systems Engineering Tour – April, 2013

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

juan.llorens@reusecompany.com

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)

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

Supports the complete system knowledge-

base for the application of semantic services

around the system life cycle (Including SE).

Manages a formal representation of the

System Assets: Requirements, Models, etc.

Is the base for offering services around these

assets

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

vehicles

Vehicles

Emissions

control

Pollution

emissions

Legislation

Environment

al impact

evaluation

vibration

conditioning

Air flow

Conduct

Diesel

engines

Gas Engines

Electric Engines

Engines

Hybrid engines

Pressure

Vehicle

structure

Window Security

Safety and

health

Hvac system

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

identify

minimum

second

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

Administrator

Standard user

Customer

Administrator

Engine

vehicles

Vehicles

Emissions

control

Pollution

emissions

Legislation

Environmental

impact

evaluation

Noise and

vibrations

conditioning

Air flow

Conduct

Diesel

engines

Gas Engines

Electric Engines

Engines

Hybrid engines

Pressure loss

Vehicle

structure

Window

Security

Safety and

health

Hvac system

Thesaurus : Example for RA

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

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

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

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

Verb Semantic

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:

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

VALUE> [NUMBER ]

Representation Schemas

Create a formal representation of the knowledge Statements based on the

Pattern information

<<Semantic of 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

VALUE> [NUMBER ]

Representation Schemas

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

than 10 units per second

Synonyms

Electromagnetic sensor

Electromagnetic device

System

Synonyms

Target

Semantic equivalences:

Identifies

Distinguish

Discover

<<Detect>>

Radar Hits

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

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

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

Requirement

Validated

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

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

contact@reusecompany.com

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

OBSE - Ontology Based System Engineering

Technology

Ontology: From Philosophy to Engineering

el obse - AEMET

Ontology Development and Engineering - UoAcgi.di.uoa.gr/~pms547/lectures/intro-to-ontology-development-with... · Ontology Development and Engineering. ... • Example: A driver can

Ontology Engineering: Tools and Catalogues - GO FAIR · 2019. 11. 6. · María Poveda Villalón, Oscar Corcho (and the Ontology Engineering Team at Ontology Engineering Group) Universidad

Computers in Industry - Vrije Universiteit Amsterdamkgf300/An exploratory study on ontology engineerin… · Ontology engineering Software architecture Software 2014 ontology Ontology-based

Ontology Engineering: Ontology evaluation

Dataset Quality Ontology - An Engineering Experience

Ontology Engineering: Introduction

Ontology Engineering: ontology construction II

Logic-based Ontology Engineering

Ontology Engineering: ontology construction I

OEG tools for supporting Ontology Engineering

Evaluating Diagrammatic Patterns for Ontology Engineering

Ontology for Big Systems & Systems Engineering

Ontology engineering ESTC2008

Collaborative ontology engineering: a survey...Ontology engineering refers to the study of the ‘activities that concern the ontology development process, the ontology life cycle,

Ontology Engineering -The DOGMA Approach - Jarrar · ontology engineering. Published as: Mustafa Jarrar and Robert Meersman: Ontology Engineering -The DOGMA Approach. Book Chapter

09.02.200 - 12 - Ontology Engineering

Ontology Engineering: Tools and Methodologies

Ontology Engineering for Big Data