SpecIF - Specification Integration Facility

News: GfSE releases SpecIF v1.1

On it’s conference Tag des Systems Engineering (TdSE) 2021 the Gesellschaft für Systems Engineering (GfSE), German chapter of INCOSE, has released SpecIF v1.1. A press statement (Pressererklärung) highlights the importance for collaboration in system design. Like all other results of the working group, the documentation has been openly published on Github.

Motivation

End-to-end Product Lifecycle Management

In the field of Systems Engineering (SE) a multitude of methods is being used with benefit every day; for example requirements mana­gement, modelling of system structure and behavior with UML/SysML or simulation with Modelica and other languages. There is infor­mation from various sources and in different formats, all providing valuable input for system design and development [3].

In practice, it is difficult or even impossible with acceptable effort to join the information and to put it in relation. Information from diffe­rent sources (“silos”) is often inconsistent, because it is main­tained by different organi­zations with their own background and purpose. Popular modelling standards such as UML/SysML are notations, but leave semantic inter­pretation to tool-makers or users. For data (model) exchange there are several standards with respect to syntax, but very few which address the semantics as well.

The Specification Integration Facility (SpecIF) shall support the change from document-centric to artefact-centric colla­boration, which is a generally accepted goal in the domains of systems engineering and product lifecycle management (PLM). SpecIF defines a language for describing system models with attention to both syntax and semantics. By creating a common context for graphical and textual content, an understanding (beyond mere communi­cation) is achieved on a logical level. Existing technical formats and protocols such as ReqIF or RDF are adopted to take advantage of existing IT infra­structure.

The motivation is also discussed in an interview Systemmodelle zusammen führen mit SpecIF on System Engineering Trends. The interview was conducted in July 2016, but is just as relevant today as it was then.

Goals

SpecIF Goals

SpecIF contributes to the following objectives:

  • Lifecycle-Management from the Beginning: Structures and content from the early phases of system conception are seam­lessly made available for development.
  • Embracing disciplines: SpecIF creates a common context for models from disciplines such as Mechanics, Electronics, Software, Safety and others.
  • Embracing methods: Texts as well as structural and behavioral models of popular methods, among others BPMN, SysML and FMC can be integrated. This means that individual elements (“resources”) exist once and may appear on several model diagrams.
  • Technology-neutral: SpecIF data can be transformed to various technical formats, such as relational datenbase, ReqIF, OSLC, XMI, graph-database or web linked-data (RDF).
  • Vendor-neutral and independent: SpecIF is not limited to certain tools or vendors; in contrast, SpecIF lets you exchange model data between different tools and organizations.
  • Schema-compliant: SpecIF data can be checked formally using a JSON- or XML-schema; the former has been made available at SpecIF-Schema.
  • Standard-compliant: SpecIF draws on existing standards, most importantly from W3C, OMG and OASIS.
  • Open and cooperative: Creative Commons BY-SA All results are published with Creative Commons 4.0 CC BY-SA license; allowing commercial use. The results can be further developed, but the origin must be stated and they must be published under similar terms; please consult the referenced license text. We encou­rage everyone interested to join our GfSE working group and to directly contribute to the results.

Use Cases

Today, there is close cooperation between product OEMs, engineering service providers and suppliers. The business processes demand easy information exchange between all participating organizations:

  • Exchange requirement-specifications and model-based system-specifications along the supply-chain.
  • Publish results (including system models) from different authoring systems, usually requiring a high level of expertise, to a far bigger group of ‘occasional’ users for inquiry, commenting or auditing. Uniform access regardless of the authoring system is best practice.
  • Show changes made over time and support the change management across organisations.

With respect to the content, information comes from different organisations and address product strategy and resulting requirements, laws and consumer protection, optimized user interaction, functions, system structure and behavior or even the validation of rqatings by means of simulation. The following tasks shall be supported:

  • Integrate information and models from different sources and in different formats,
  • Search and navigate consistently,
  • Find and consolidate identical elements in different models,
  • Detect and store dependencies and logical relations between model elements, essentially that is interrelating model elements with a semantic net,
  • Detect errors, inconsistencies or violations of design rules,
  • Reference (‘trace’) artefacts in subsequent development steps without copying.

Method

Levels of Information Representation

Levels of Information Representation

The goal is to combine information from various sources provided in different notations. Not only the visible is to be taken into account, but also the meaning. SpecIF brings the information in a common logical context and stores it using well known technologies.

Four abstraction levels are used:

  • The format or medium carries the information to the reader, for example a booklet, a PDF-docu­ment for presentation with a specific software application or as HTML5-document for display in a web-browser.
  • The notation defines how information is represented, that is how it looks like. The examples shown are text divided in titles and paragraphs, structured data in a table, BPMN process diagram and SysML block diagram.
  • The integrated model holds the semantics, the meaning of the combined information, independently of their respective notation. It lends itself for analysis by machine, overall search as well as navigation.
  • The entities and relations on the lowest level store the information, where many known technologies may apply.

Fundamental Resource Types

A logical integration of model information prepared using different notations is made possible by abstraction of model elements to very few fundamental element types. Based on scientific research and practical experience, five model element types are proposed [9]:

  • An ■ Actor represents an active entity, be it an activity, a process step, a function, a system component or a role.
  • A ● State stands for a passive entity, be it a value, a document, an information storage or even a physical shape.
  • An ♦ Event constitutes a time reference, a change in condition/value or more generally a synchronisation primitive.
  • A ↯ Requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.
  • A ✶ Feature is an intentional distinguishing characteristic of a system, often a unique selling proposition.

The Fundamental Modelling Concepts (FMC) conceived by Prof. Dr. Siegfried Wendt, founding director of the Hasso-Plattner-Institute Potsdam, and his research team show, that all models of known methods can be constructed using three model element types Actor, State and Event [1,2]. Requirement and Feature have been added for textual information complementing the models.

Syntax

Within the SpecIF schema, the information model (meta-model) specifies the resource classes and statement classes that will be available for the system model.

  • Resource-classes such as ‘Requirement’ oder ‘System component’,
  • Statement-classes such as ‘contains’ or ‘satisfies’, where the permissible Resource-types for subjects and objects of any statement instance can be specified for convenience.
  • Hierarchy-classes such as ‘Document outline’ or ‘Bill of Materials’, providing a linear and hierarchical view on the model elements.

All Classes may have an individual set of Property-classes with permissible value range each. For example, a ‘Requirement’ may have the properties ‘Title’, ‘Description’ and ‘Priority’.

The resources, relations and hierarchies with their properties are instances of the respective classes. A SpecIF data-set contains both the classes and instances, so that not only the values, but also their classes with value ranges are known by all consumers.

Semantics

Ontology

Good understanding is based on a clear vocabulary or ontology for the respective domain. This is true both for communication involving people as well as systems.

For example, ReqIF is a format for information exchange standardized by the OMG [5], but is effectively used when applying the naming convention for the information elements which have been introduced by the ReqIF Implementor Forum of the ProSTEP iViP e.V.. Similar conventions have been published by the OSLC initiative. Interestingly, in both cases there are only names for the attributes, but not for the resources themselves: For example, the property carrying a descriptive text is named ReqIF.Text resp. dcterms:description, but there is no name for the requirement as a whole, such as ReqIF.Requirement oder oslc_rm:requirement (or whatever term may have been chosen).

SpecIF proposes an ontology comprising names for resources and statements, as well as their properties and values. The conventions or definitions of Dublin Core, OSLC, IREB and other open standards are re-used whenever possible. The ontology itself is available in SpecIF-Format.

Logical Statements

Logical Statements

Relations between information elements express further meaning; they correspond to statements or assertions like ‘Subject Predicate Object’, where subject and object are information elements or ‘resources’. Some statements have to be made manually by the analyst or system designer/architect, for example ‘Component-XY satisfies Requirement-4711’. Most relations, however, can be derived automatically from the model diagrams, usually from the vertices between nodes.

By expressing the meaning depicted by model diagrams with explicit statements, navigation as well as automated graph-search and consistency checks are made possible:

  • It is easy to query using dependencies, such as: ‘Which parts are affected, if Requirement-123 is changed?’ or ‘Which components may write to database-AB?’. The meaning of the model is unlocked for machine evaluation.
  • If one diagram shows that Component-N contains Component-M and another diagram shows the opposite, and if the relations are available explicitly and not only by a line on a diagram, it is easy to detect the inconsistency.

Essentially the SpecIF Integration-model consists of model-elements (resources with their properties) and logic statements using them. It is a semantic net which can be mapped to many technical formats, be it graph- or relational databases, JSON-files, linked-data for the world-wide-web and others.

Principles of Model-Integration

The following five principles of semantic integration have been developed in various projects [7,8]:

  • Separation of presentation and model: Hierarchical outlines, lists, texts and diagrams are all views of a common model.
  • Abstraction of model elements: The common model consists of elements of the fundamental element types Actor, State and Event, complemented by Feature and Requirement. Specific models are transformed to the SpecIF Integrated Model according to the fundamental characteristic of their elements. The Integrated Model creates a common context for all.
  • Consolidation: Identical model elements on multiple diagrams (with the same or different notations) represent the same element in the Integrated Model.
  • Semantic interrelation: Logical dependencies between model elements are stored with explicit relations, which can be derived automatically or by a user.
  • Ontology: A common terminology (glossary or ontology) simplifies the data exchange between systems, because entities and attributes can be collated automatically according to the respective data models. Also the understanding between project partners is improved, as terms with agreed-upon meaning are employed.

Schema

For system specifications represented by SpecIF data in JSON format a schema is being developed publicly on Github. Furthermore, implementations of a schema-check and a constraint-check have been made available.

CORS-enabled hosting:

Applications and suggestions are welcome!

Examples

Two examples belonging to the application domains mechatronic systems and enterprise IT are described in [11], chapter 5. It is shown how process-models, system-structures and requirements are interrelated and which are the practical benefits.

The examples are stored in a data set following the current version of SpecIF. Technically speaking you find ZIP-files containing the model-information in JSON format plus the images referenced by the model. A hierarchical document outline lets you comfortably read the content, whereas the relations let you browse the semantic net.

Notice: The first two examples have been created using the method ‘Fundamental Modelling Concepts’ (FMC). Please do not infer that model integration with SpecIF can only be achieved using FMC. In contrary, current research shows that transformation of SysML Model diagrams to SpecIF is possible; the first results are shown in the third example. We are looking for further examples to formalize the transformation.

The goal of SpecIF is to develop conventions to facilitate the use of system models independently of certain methods and tools. SpecIF is first mapped to the OMG Requirements Interchange Format (ReqIF), so that all tools supporting ReqIF can be used to work with SpecIF models.

First Steps

Are you interested and would like to investigate the SpecIF approach more in detail? Let us give you some links where you could start:

If you have any questions, please contact Uwe Kaufmann, Oliver Alt or Oskar v. Dungern using the contact information given below. Suggestions and contributions are welcome!

Cooperation

The results are continuously detailed and validated by:

The SpecIF Initiative is being supported by (in alphabetical sequence):

  • Abulawi, Prof. Dr.-Ing. Jutta, Hochschule für Angewandte Wissenschaften Hamburg
  • Alt, Dr.-Ing. Oliver, Karl Mayer Textilmaschinenfabrik GmbH, Obertshausen
  • Dungern, Dr.-Ing. Oskar von, enso managers GmbH, Berlin
  • Eichmann, Oliver, TU Hamburg
  • Giertzsch, Fabian Maximilian, TU Hamburg
  • God, Prof. Dr. Ralf, TU Hamburg
  • Jastram, Dr. Michael, Formalmind GmbH, Düsseldorf
  • Kaufmann, Uwe, model alchemy, Berlin
  • Koch, Dr.-Ing. Walter, GfSE e.V,
  • Pfenning, Michael, XPLM Solution GmbH, Dresden
  • Priglinger, Dr. Siegmund, dr.priglinger consulting GmbH, Wien
  • Reichardt, Winfried
  • Schuler, Prof. Dr.-Ing. Ralf, Hochschule Esslingen
  • …

Interested to support the SpecIF Initiative with active collaboration on theoretic fundementals or on practical application or simply with „moral support“?

Contact

Institution

GfSE-Logo

The SpecIF initiative is hosted by the Gesellschaft für Systems Engineering e.V. (GfSE), German Chapter of INCOSE.