Exchanging System Models with SpecIF
In the field of Systems Engineering (SE) a multitude of methods is being used with benefit every day; for example requirements management, modelling of system structure and behavior with UML/SysML or simulation with Modelica and other languages. There is information from various sources and in different formats, all providing valuable input for system design and development .
In practice, it is difficult or even impossible with acceptable effort to join the information and to put it in relation. Information from different sources ("silos") is often inconsistent, because it is maintained by different organizations with their own background and purpose. Popular modelling standards such as UML/SysML are notations, but leave semantic interpretation 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 collaboration, 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 communication) is achieved on a logical level. Existing technical formats and protocols such as ReqIF or RDF are adopted to take advantage of existing IT infrastructure.
SpecIF contributes to the following objectives:
- Lifecycle-Management from the Beginning: Structures and content from the early phases of system conception are seamlessly 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: 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 encourage everyone interested to join our GfSE working group and to directly contribute to the results.
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.
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-document 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 :
- 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.
Within the SpecIF schema, the information model (meta-model) specifies the resource types and statement types that will be available for the system model.
- Resource-types such as 'Requirement' oder 'System component',
- Statement-types such as 'contains' or 'satisfies', where the permissible Resource-types for subjects and objects of any statement instance can be specified for convenience.
- Hierarchy-types such as 'Document outline' or 'Bill of Materials', providing a linear and hierarchical view on the model elements.
All Types may have an individual set of Property-types 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 types. A SpecIF data-set contains both the types and instances, so that not only the values, but also their types with value ranges are known by all consumers.
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 , 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 a vocabulary comprising names for ressources and statements, as well as their properties. The conventions or definitions of Dublin Core, OSLC, IREB and other open standards are re-used whenever possible. The vocabulary itself is available in SpecIF-Format.
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.
- Vocabulary: 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.
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.
Applications and suggestions are welcome!
Two examples belonging to the application domains mechatronic systems and enterprise IT are described in , 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.
- Semantically integrated system model of a dimmer: ZIP-file with JSON pursuant SpecIF V 0.10, ePub-file and Online Demo
- Semantically integrated process- und IT-documentation: ZIP-file with JSON pursuant SpecIF V 0.10, ePub-file and Online Demo
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.
The results are continuously detailed and validated by:
- GfSE Working Group "Integration of MBSE and PLM" (PLM4MBSE)
A research project named „SEISMIK Service Entwicklung für die inter-disziplinäre System-Modellierung – eine Initiative von KMU“ has been submitted for funding.
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, Polygon GmbH, Obertshausen
- Dungern, Dr.-Ing. Oskar von, adesso AG, Berlin
- Jastram, Dr. Michael, Formalmind GmbH, Düsseldorf
- Kaufmann, Uwe, model alchemy, Berlin
- Pfenning, Michael, XPLM Solution GmbH, Dresden
- Priglinger, Dr. Siegmund, dr.priglinger consulting GmbH, Wien
- 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“? Please contact us: Oskar v. Dungern or Uwe Kaufmann.
|||Wendt, S.: Ein grundlegender Begriffsrahmen für das Wissensmanagement im Software-Engineering. In Proceedings „Knowtech“ Dresden 2001|
|||Knöpfel, A.; Gröne, B.; Tabeling, P.: Fundamental Modelling Concepts – Effective Communication of IT Systems. ISBN-13: 978-0-470-02710-3. John Wiley&Sons, Chichester, 2005.|
|||Kaufmann, U., Pfenning, M.: 10 Theses about MBSE and PLM,|
|||Object Management Group: Systems Modeling Language (OMG SysML™), Version 1.3, June 2012|
|||Object Management Group: Requirements Interchange Format (ReqIF)|
|||Open Services for Lifecycle Collaboration (OSLC)|
|||Dungern, O.v.: Semantic Model-Integration for System Specification – Meaningful, Consistent and Viable, 7.Grazer Symposium Virtuelles Fahrzeug, Graz, Mai 2014.|
|||Dungern, O.v.: Übergreifende Konzeption von Geräten für die Gebäudeautomation – Methodik und Management. TdSE Tag des Systems Engineering der GfSE, Bremen, November 2014.|
|||Dungern, O.v.: Integration von Systemmodellen mit fünf fundamentalen Elementtypen. TdSE Tag des Systems Engineering der GfSE, Ulm, November 2015.|
|||Dungern, O.v.: Von Anforderungslisten zu vernetzten Produktmodellen – am Beispiel der Gebäudeautomation. REConf, März 2016 Unterschleißheim.|
|||Dungern, O.v.: Semantic Model Integration for System Specification - Creating a Common Context for Different Model Types. TdSE Tag des Systems Engineering der GfSE, Herzogenaurach, Oktober 2016.|
|||Dungern, O.v.; Uphoff, F.: Der ‚Interaction Room‘ bahnt einen natürlichen Weg zu vernetzten Systemspezifikationen. REConf, März 2017 München.|
|||Dungern, O.v.: How to Automatically Understand and Integrate System-models … and how SpecIF can help. GfSE EMEA Workshop Mannheim, September 2017.|
|||Mochine, Ph.; Sünnetcioglu, A.; Dungern, O.v.; Stark, R.: SysML-Modelle maschinell verstehen und verknüpfen. TdSE Tag des Systems Engineering der GfSE, Paderborn, November 2017.|