a domain-aware framework for integrated model-based system ... · a domain-aware framework for...

A Domain-aware Framework for Integrated Model-based SystemAnalysis and Design

Adrian Rumpold, Reinhard Pröll and Bernhard BauerInstitute for Software & Systems Engineering, University of Augsburg, Augsburg, Germany

Keywords: Domain-specific Modeling, Model Transformation, Model-based Analysis.

Abstract: The increasing complexity of modern embedded systems demands advanced design and development methods.Incremental evolution of model-based engineering practice has led to heterogeneous tool environments withoutproper integration and exchange of design artifacts. These problems are especially prevalent in tightlyregulated domains, where an independent assessment is required for newly developed products, e.g. inautomotive or aviation systems. To address these shortcomings of current engineering practice, we propose aholistic model-based approach for the seamless design and development of an integrated system model. Wedescribe an embedding of a variety of domain-specific modeling languages into a common general-purposemodeling language, in order to facilitate the integration between heterogeneous design artifacts. Based on thisconceptual modeling approach, we introduce a framework for automated model-based analysis of integratedsystem models. A case study demonstrates the suitability of this modeling and analysis approach for the designof a safety-critical embedded system, a hypothetical gas heating burner.

1 INTRODUCTION

Embedded systems have continuously grown in bothhardware and software complexity in recent years,with the advent of advanced functionality in manydomains, such as automotive, aviation, and industrialautomation.

System designers have attempted to cope withthis increased complexity in two major ways:First, stricter engineering methodologies have beenapplied during the design and implementationof embedded systems, with a general trendtowards model-based technologies. However,these model-based approaches have mostly beenlimited to the behavior and structure of the systemunder development, leaving aside non-functional andquality aspects.

Second, a very heterogeneous tool landscapehas emerged to conquer the immense varietyof non-functional aspects for such complexsystems – covering legislative and regulatoryissues, performance and timing requirements,and organizational factors (see chapter 4.1.2 ofSommerville (2011)).

Due to this asymmetry between partial adoptionof model-based techniques and inconsistenttooling environments, establishing traceability

and consequent change management have emergedas two main challenges in systems engineering. Theimportance of these fields can be seen clearly in thecontext of safety-critical systems, where regulationsrequire a careful management of developmentprocesses and artifacts with regard to consistenttraceability throughout the product life cycle – forexample the European IEC 61508-1:2010 (2010)functional safety standard.

The resulting need for careful manual review andmanagement of traceability and consistency leads tosub-optimal process efficiency and potential negativeimpact on product quality.

Problem Statement

The current state of the art in embedded systemsengineering therefore can be improved through amore tightly integrated approach to model-basedsystems engineering.

Despite some effort towards model exchangebetween model-based engineering tools, e.g. throughstandardized interchange formats like XMI, seamlesstool integration remains a fundamental challenge.The resulting need for manual process steps canlead to postponed quality-related design activitiesand consequently reduced overall product quality and

Rumpold A., PrÃull R. and Bauer B.A Domain-aware Framework for Integrated Model-based System Analysis and Design.DOI: 10.5220/0006206301570168In Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2017), pages 157-168ISBN: 978-989-758-210-3Copyright c© 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

157

increased cost of quality defects discovered late in thedevelopment process.

Furthermore, textual artifacts, such asdocumentation required for safety certification,highlight the critical role of consistency betweendesign models and the textual artifacts generatedfrom them. Whereas common modeling tools allowfor generation of technical documentation fromsystem models, the generation of more complextextual artifacts exceeds their limited capabilities.

In order to overcome the identified weaknesses,we propose an approach which aims for a tightintegration of all system modeling artifacts and shifttowards (semi-)automated integrated architectureanalyses.

Based on an extensible set of domain-specificmodeling languages, which make up a solidfoundation for a more suitable description of qualityaspects, we aim for a co-evolution of functionaland quality architectures of the system underdevelopment.

Through this strict model-based approach, thereuse of existing design methodologies is guaranteed,as long as their results can be formalized using anunderlying metamodel. Consequently, this leads toa higher level of model consistency and improvedcapabilities for impact analysis.

The model-level integration of multipledomain-specific aspects additionally enablesdevelopers to make use of model-based documentgeneration, which offers the flexibility mandated bythe development of complex embedded systems.

We foresee that this integrated modeling approachwill lead to increased product and documentationquality and can thus support the development ofsafety-critical and similarly regulated systems.

Outline

Section 2 provides an overview of the fundamentalmodeling concepts in our approach and their rolesduring integrated system analysis and design. Startingwith general-purpose modeling languages and theiruse inside our conceptual framework, we list a setof essential domain-specific views on the system andtheir embedding into the general-purpose language.Based on this definition of embedded domain-specificlanguages, we describe a model-based analysisframework in Section 3. In Section 4, we demonstratethe feasibility of our proposed approach using arealistic use case. There, we perform some exemplarydesign and analysis steps regarding the functionalsafety of a hypothetical gas heating burner. Section 5discusses related work regarding the integration

of heterogeneous modeling tools, domain-specificmodeling, and model-based analysis. Section 6summarizes the key results presented in this paperand suggests possibilities for future work based on ourcurrent research.

2 A DOMAIN-AWARE APPROACHFOR SYSTEM MODELING

To overcome the previously identified problems,we have developed a concept designed to integratelegacy development and modeling technique witha new kind of domain-aware modeling approachand analysis framework. Based on the informationembedded in an integrated system model, textualartifacts, which had to be maintained manuallybefore, can now be generated automatically. In orderto switch between these representations and generatedocuments, we make use of model-to-model (M2M)and model-to-text (M2T) transformations.

The high-level concepts and their internalrelationships are illustrated in Figure 1 and will beelaborated in the following sections.

2.1 General Purpose ModelingLanguages

Following our goal of easy application and seamlessintegration into state-of-the-art developmentprocesses, we have decided to embed all relevantdata for the development process within a GeneralPurpose Modeling Language (GPML), such as UMLor Ecore. The major advantage of this decision isthe reuse of modeling editor capabilities and thepreexisting wide range of general purpose modelingtools.

These general-purpose languages serve a two-foldpurpose: First, they provide a common modelingbasis for all domain-specific aspect models, asdescribed in the following section. Second, theGPML can itself be used to cover certain subsetsof the domain-specific modeling disciplines, if theirexpressive power is sufficient for a specific project.We will see an example for this simplified domainaspect modeling in the case study in Section 4, whereUML component diagrams and state machines areused to describe parts of the system architecture.

Our approach does not prescribe a certain GPMLto be used for modeling the integrated systemmodel. The only necessary requirement is thepossibility to enhance the general-purpose languagewith metamodel extensions. In the case of UML

MODELSWARD 2017 - 5th International Conference on Model-Driven Engineering and Software Development

158

General Purpose

Modeling Languages

Domain-Specific Modeling Languages

...

Purpose-Specific

Documentation

M2M

Timing

Test

(TD)

Integration

(IM)

Security

System

Structure

(SSD)

Safety /

Reliability

(SRD)

Requirements

(REQ)

EMOF/CMOF

Ecore

Safety Cases/

Certification

Documentation

Technical

Documentation

Traceability

Documentation

System

Behaviour

(SBD)

Code Artifacts

(out of scope)M2T

UML +

Profiles

Figure 1: Conceptual overview of the architecture and analysis framework.

this is achieved by defining profiles that leveragethe stereotype mechanism. Similarly, we can extendthe expressive capabilities of modeling languageswhich are themselves specified as UML profiles, forexample SysML. Within the widely popular EclipseModeling Framework (EMF), metamodel extensionscan be easily defined due to the reflexivity of theEcore modeling language, which itself is its ownmeta-model.

2.2 Domain-specific ModelingLanguages

In order to accurately describe domain-specificaspects of the system under development, weembed them into the GPML mentioned above asdomain-specific modeling languages (DSML). Ourapproach allows for any number of DSMLs to be usedin conjunction with a general-purpose modeling toolto obtain an integrated system model (ISM) or Omnimodel.

These DSMLs preserve the separation ofconcerns, but enable developers to link informationacross domains in order to build up a holistic view ofthe system under development (SUD) and facilitateanalyses based on domain-specific information.

In this section we briefly introduce somecommon domains and their focus, laying theconceptual groundwork for the following sections thatwill provide additional detail and demonstrate theapplication of these concepts.

The Requirements Domain (RQD). is related tothe very first engineering tasks of every modernsoftware development process. As a result of thesetasks, a set of requirements are extracted, whichdescribe the desired system from a functional aswell as a quality perspective. In order to furthermake use of the generated set of requirements,

a certain DSML needs to be defined. Naturallanguage requirements with additional structuringcapabilities as well as fully machine-processablerequirement models are thinkable. For example aReqIF-based DSML (see OMG REQIF v1.2 (2016))can be used with most common CASE tools. Beingable to reference specific requirements in a modelor parts of them, enables developers to furtheruse this semi-formal specification of the systemfor cross-domain traceability, thus extending theinformation base.

The System Structure Domain (SSD). containsthe structural model of the system under developmentand reflects the architectural decomposition of thesolution.

Our approach allows for a high degree offreedom regarding the actual implementation of theSSD model. For simple projects, the underlyingGPML (see Section 2.1) itself may be sufficientlyexpressive to model the system structure withoutany domain-specific additions. For more complexsystems, a modeling language with more powerfulabstractions, such as SysML, can be integrated todescribe the structural domain more adequately.

It should be noted that the SSD model may alsobe derived from a prior system description in caseof a brown-field project. Here, it is feasible to useeither existing architecture models as a basis for thenewly defined integrated system model, or to reverseengineer a system description from its code artifacts.

The System Behavior Domain (SBD). containsmodeling artifacts that describe the functionalbehavior of the system under development. Asdescribed above for the SSD, a range of modelinglanguages can be used to implement the behavioralmodel within our approach. Natural choices are thebehavior diagrams found in the Unified Modeling

A Domain-aware Framework for Integrated Model-based System Analysis and Design

159

Language or its SysML extension.However, different domain-specific modeling

languages might be more familiar to designersof certain embedded systems; one example isthe Function Block Diagram (FBD) notation forprogrammable logic controllers defined in theIEC 61131-3 and IEC 61499 international standards.

Given a suitable technology integration bridge(e.g. OSLC or ModelBus, see also Section 6),it is conceivable to integrate behavioral modelsfrom widely used simulation tools like Simulinkor Stateflow, as an intermediate step whilere-engineering legacy systems.

The Safety and Reliability Domain (SRD). coversthe modeling and analysis of system reliability.Such analyses are invaluable and often mandated byregulations, e.g. in the development of safety-criticalsystems, to demonstrate the system’s expected failurebehavior and obtain measures of reliability andavailability.

In order to quantify the reliability of a system,a thorough analysis of potential hazards andtheir associated risks is required. These hazardanalyses require profound domain knowledge and arefrequently performed as team efforts. Despite theinteractive nature of these activities, their results canbe formalized in the form of a hazard model thatdescribes identified hazards and the risks as wellas possible faults and failures that can cause thesehazardous events.

A major task in the design of safety-criticalsystems is the classification of hazards based on theirassociated risk. Risks that are deemed intolerable,either by societal or regulatory standards, have to bemitigated by targeted risk reduction measures. Basedon the necessary level of risk reduction, levels ofsafety integrity and associated safety requirementscan be allocated to protective system components.This SIL allocation process requires the quantitativeanalysis of failure occurrence likelihoods.

Traditionally, such quantitative reliability modelsare maintained in separate tool environments,decoupled from the actual system model. This setupcan lead to inconsistencies in reliability models anddecisions made based on them, when proper care isnot taken during ongoing development of the system.However, many common of the traditional reliabilitymodeling approaches can easily be adapted for use inmodel-based environments. For example, the widelyused Fault Tree Analysis (FTA) technique defines aset of graphical model elements to analyze failurecauses in a system Vesely et al. (1981), and provesa suitable candidate for a domain-specific modeling

language with a familiar graphical representation.By embedding the reliability and hazard analysis

models into the integrated system model, ourapproach allows to easily maintain full traceabilitybetween these models and their associated systemmodel counterparts in the SSD and SBD. Moreover,change impact analyses can be easily performedbased on this traceability information, whenever amodification to any part of the system model is made.

In the context of model-based systemsengineering, it makes sense to move beyondthe traditional FTA technique and incorporate acomponent-based extension, such as the ComponentFault Trees as proposed in Kaiser et al. (2003). Thishierarchical structuring of reliability informationcreates synergies with the end-to-end traceabilityprovided by our modeling approach.

The Test Domain (TD). reflects the informationspecific to the tester’s view on the system underdevelopment. It can be used to formalize artifactsrelated to quality assurance activities, such as testplans, test cases, and test execution reports.

However, the true strength of the test domainmodel lies in the integrated support for model-basedtesting approaches. Depending on the expressivenessof the modeling languages used for the systemdescription in the SSD and SBD, the test domaincan be simply seen as an extension of thesedomains. However, it is also conceivable to embedmodel languages specific to the testing domain,such as the OMG-maintained UML Testing Profile,which provides modeling facilities for test behaviordescription as well as quality assurance managementactivities.

The Integration Model (IM). as illustrated inFigure 1, marks the central model artifact in orderto establish a mechanism for domain-specific modellinking and mapping of artifacts. The cross-domainlinking, represented by the bidirectional connectors,on the one hand enables developers to make use ofa solid and consistent tracing mechanism applicablethroughout all development artifacts. On theother hand the IM is meant to provide additionalinformation to the test engineer, previously out ofscope. Therefore, distinct elements of the systemmodel are mapped via the IM to concepts used in thetest model. This also holds for other combinationsof domain-specific model data. Note, that the IMdoes not model any information that has already beenmodeled in a connected domain. It only holds asubset of the resulting data generated by analysesperformed on linked domains and establishes the


160

connections between its model artifacts. A necessaryprecondition for the seamless integration of allconnected information domains is a common M3metamodel definition for the tracing specific DSLparts.

Other Domains. The above modeling domainscover a wide range of engineering artifacts relevantduring the design and construction of embeddedand/or safety-critical systems. However, ourmodeling approach does not prescribe a fixed setof domain-specific modeling languages and domainsand can easily be extended and tailored to eachspecific modeling use case.

The set of modeling domains presented aboveare relevant to the design of embedded systemsin particular. However, our framework may alsotake into account aspects of business and otherapplications. To this end we envision domainsaddressing security and privacy considerations(e.g. to model information flows), timing models,description of data persistence, as well as usabilitymodels.

2.3 Purpose-specific Documentation

While the domain-specific models describedabove are derived from the GPML model throughmodel-to-model transformations, our approach alsocovers the generation of purpose-specific textualartifacts through model-to-text transformations.

The automated generation of textualdocumentation is an important step towards moretightly integrated system engineering processes andplays a crucial role in the quality-driven architecture.The continuous and early design-time availability oftextual design artifacts can support the subsequentfulfillment of process requirements.

The holistic nature of our proposed integratedsystem modeling approach facilitates documentgeneration on a high abstraction level. For example, acommon documentation requirement in safety-criticalsystems calls for seamless forward and backwardtraceability from system requirements down to theimplementation level and its proper documentation.Since the Omni model contains all necessaryarchitectural elements and their relationships,generating such documentation consistently and in aneasily navigable format (for example as hyperlinkedHTML documents) is an effortless automated task.

The use of hypertext formats is superior totraditional documentation formats for results ofpreliminary risk and hazard assessments. Currentdocumentation artifacts used for the certification

of safety-critical systems commonly relies onspreadsheets and static PDF documents for thispurpose. Using hypertext formats elegantly solves theproblem of limited traceability of these documents.Since an HTML document allows to directly placelinks between the results of these assessments, theirassociated model elements, and related documents.This improvement allows easier familiarization withthe system and better comprehension both as systemdocumentation and for certification purposes.

Similarly, more formal certification artifacts canbe generated from the integrated system model:The Goal Structuring Notation (GSN) is a graphicalnotation for representation of structured arguments,as in the case of safety or assurance cases forsafety-critical systems Kelly and Weaver (2004).Hereby, the purpose of a formal argument notationis to tie claims about the safety of the system underdevelopment together with supporting evidence.Here, our approach can be used to generate a coherentset of safety documentation following the structuredargument of a given GSN model based on the entireset of domain-specific models and analysis resultscontained in the integrated system model.

The availability of usable, consistent, andup-to-date textual artifacts can help to reduce costof safety certification by supporting high quality andearly review of certification-related documents.

Additionally, the same model-based documentgeneration approach can be used to capture theresults domain-specific analyses of the system thatcover individual stakeholders’ interests. From aproject management standpoint, we envision thisapproach to be useful for analyzing certain KeyPerformance Indicators of the system, for exampletest and requirement coverage metrics as an indicatorof overall project progress.

2.4 Code Generation

While out of the direct scope of our research, it shouldbe noted that the final integrated system model isa suitable basis for generation of source code, asindicated by the second model-to-text transformationstep in Figure 1. The integrated nature of the Omnimodel allows the code generation engine to makemore educated decisions about the context of thesource code to be synthesized. A possible scenariocould be the automated application of defensiveprogramming techniques in generated code, e.g.pre- and post-conditions or checksums, based oncomponent contracts or safety requirements from theintegrated system model.


161

3 MODEL-BASEDARCHITECTURE ANDANALYSIS FRAMEWORK

Based on the modeling approaches introduced in theprevious section, we have developed a technologydemonstrator geared towards the domain-awaremodeling of safety-critical systems and their qualityattributes. In addition to the domain-specificmetamodels, the prototype includes a framework fordefinition of domain-specific architecture analyses,introduced below in Section 3.2.

3.1 Technical Background

As shown in Figure 2, the analysis framework consistsof three major components:

• Enterprise Architect as a general purposemodeling tool, used to provide the user interfacefor the system designer (Section 3.1.1)

• A relational database system for persistent storageof the model repository (Section 3.1.2)

• The actual architecture and analysis framework,which offers model analysis services via a webservice interface (Section 3.1.3)

3.1.1 Domain-specific Modeling in GeneralPurpose Modeling Tool

The commercially available modeling and designplatform Enterprise Architect (EA) by SparxSystems serves a the central modeling tool for ourdemonstrator. As a general purpose modeling tool,it fully supports the UML 2.5 specification andincludes an extension mechanism (dubbed MDGTechnologies) as an implementation of UML profilesfor use inside the EA modeling environment.

These MDG technology specifications can extendexisting UML metaclasses as stereotypes with newattributes and define custom visual representationsfor use of these stereotypes in diagrams. We havedeveloped custom MDG technologies for each ofthe domain-specific metamodels introduced in theprevious section, to create the necessary modelingvocabulary to the system designer.

3.1.2 Shared Model Repository Access

In its current form, the analysis server accesses theintegrated system model through a relational databasewhich is configured as the model repository insideEnterprise Architect. A custom-built object-relationalmapper (EAORM) provides programmatic access to

the model repository and allows for its consistentmodification. As described in Section 6, in thefuture we aim to replace this rather tight couplingbetween the tools by means of a model-orientedinteroperability platform, such as ModelBus.

3.1.3 Analysis Framework Integration

In order to anticipate a wider range of modeling tools,our analysis framework has been implemented as astand-alone component outside the general purposemodeling environment. The functionality of theframework core is exposed through a graphical userinterface for rapid feedback during development ofmodel analysis, and a server component for remoteaccess to the analysis functionality.

It provides a RESTful web service interface tothe model analysis and textual artifact generationfunctionality. Communication between EA andthe analysis framework is brokered by a thin webservice client implemented as a custom plug-in insideEnterprise Architect.

It should be noted that no model representationis exchanged via the web service interface. Instead,both tools share access to a common model repository(see below), enabling them to refer to model elementssolely by their identifiers. This approach allows theanalysis framework to access a native representationof the entire integrated system model. While a genericmodel interchange format like XMI might satisfy therequirements for unidirectional exchange of modeldata between tools, problems arise in scenarios wherebidirectional access is required. In order to keep themodel consistent, the analysis framework needs to beable to persist the results of its analyses in the samemodel as its input data, therefore bidirectional accessto the model is essential.

The clear architectural separation betweenmodeling and analysis functionality facilitatesanother important use case: The analysis frameworkcan be used independently from the design tool, forexample as part of a continuous integration pipeline.Since all functionality of the framework is offeredthrough a programmatic interface, the only necessaryaddition is a machine-readable description of theanalyses to be executed. Such descriptions can evenbe stored as part of the integrated system model,creating a truly self-contained system model thatspans the entire product lifecycle.

We have chosen the Operational QVT language(QVTo for short, see OMG QVT v1.3 (2016);Kurtev (2007) for details) as the model-to-modeltransformation language for our prototype. Eachdomain-specific model can be obtained from theintegrated system model by applying its associated


162

Figure 2: Technical overview of the reference technology platform architecture. Components shaded in dark gray refer tofuture extension possibilities, as described in Section 6.

transformation that maps the extended generalpurpose modeling language (see Section 2.1) onto thedomain-specific modeling languages (Section 2.2).In order to simplify the integration with theEclipse EMF-based QVTo implementation used, alldomain-specific models have been implemented asEcore metamodels.

Model analyses can define dependencies on thedomain models necessary for their execution. Thetransformation engine in the analysis frameworkautomatically determines the appropriate M2Mtransformations to be applied to the integrated systemmodel when performing a model analysis.

3.1.4 Model-to-text Transformation

Since our prototype is focused on documentgeneration as HTML pages, a general purposetemplating language (Jtwig) was used formodel-to-text transformation instead of a moreformal M2T language. However, depending on theexact nature of the output format, M2T languagessuch as Eclipse Xtend or Xtext might provide moreappropriate expressive capabilities – especially ifthe resulting textual artifacts should be expressedin a domain-specific language or integrated with anexisting tool chain.

Code generation from the system model wasbeyond the scope of our developed prototype. For thepurpose of our study, generation of C code from theintegrated system model was delegated to an existingembedded systems engineering toolchain, that wasadapted to make use of the additional domain-specificinformation contained in the Omni model.

3.2 Model-based Analyses

As part of the framework prototype, we havedeveloped a range of model analyses, that can

be applied to the integrated system model and itsconstituent domain-specific models.

Conceptually, we have identified three majorclasses of model analyses, that can be distinguishedby their types of input and output models:

Validation Analyses. consume one or multipleinput domain-specific models, but do not generateany new model elements as their output. Rather, avalidation analysis verifies the syntactic and semanticwell-formedness of its input models. In case thisvalidation fails, the analysis produces a report ofthe identified violations and returns it as a separateanalysis result to the client.

Therefore, the purpose of validation analyses isthe assurance of model integrity and quality. Theyare feasible candidates for tighter integration withthe modeling environment, and can be executedcontinuously without user interaction to provide rapidfeedback to the designer about the state and quality ofthe model being modified.

Note, that the existence of this class ofanalyses is a testament to the state of metamodelextensibility in current general-purpose modelingtools. Schleicher and Westfechtel have alreadyhighlighted this shortcoming in their 2001 paperand identified it as the primary driver for so-calleddescriptive stereotypes. If GPML tools providedfirst-class support for restrictive stereotypes or evenfull restrictive metamodel extensions instead, thesyntactic and semantic constraints for a DSMLcould be directly validated as part of the metamodelextension.

Calculation Analyses. consume one or more inputdomain-specific models and calculate additionalattributes for existing model elements, but do not addnew elements.


163

These analyses can be seen as the formalizationof a function application to their input models.Examples for this class of analysis are numerous, e.g.the automated update of probability information inreliability models, risk classification, or the analysisof timing bounds in behavioral models.

In our analysis framework, calculation analysesare an obvious application point for the ModelAnalysis Framework (MAF) described by Saad andBauer (2013), which uses an application of data-flowanalysis techniques originally introduced in compilerconstruction.

Generative Analyses. both consume and producemodel elements in one or more domain-specificmetamodels. As such, they are similar tomodel-to-model transformations, however, theirpurpose is more broad, so that they should beconsidered as a separate entity. Additionally, byimplementing this type of transformation as ananalysis inside our framework, they share a commoninterface with the remaining classes of analyses,helping to reduce complexity for the client.

Depending on their respective purpose, wecan further distinguish endogenous and exogenousgenerative analyses, similar to the distinction foundin the model transformation world.

Possible uses of this class of analyses are verybroad: One possible example is the support of thesystem designer through wizard-type functionality,for example to generate skeleton reliability modelsfrom an existing structural model of a system.A different application scenario is the automatedcreation of a test model and test cases fromthe abstract description of system structure andfunctionality in the integration model.

Lastly, generative analyses can be used as theentry point for model-to-text transformations. Theycan be used to provide a consistent interface to makethe creation of textual artifacts transparent to theclient, hiding the added complexity of the actualinvocation of the M2T transformation engine.

Analyses in our framework can be chainedtogether to form more complex analysis scenarios.In order to guarantee consistency, analyses candeclare execution order constraints. The analysisframework then determines an appropriate orderingof eligible analyses, performs the necessary M2Mtransformations, and then executes the actual analysiscode.

4 CASE STUDY: RELIABILITYMODEL FOR A GAS HEATINGBOILER

In the following section we will demonstrate theuse of our domain-specific modeling approach to thereliability analysis of a gas heating boiler. Suchboilers are commonly found in residential buildingsto provide central heating by combustion of naturalgas in a burner. The natural gas used in such a heatingis highly flammable. Therefore, the design of such asystem must include an evaluation of the safety risksand reliability of its protection systems, to minimizethe risk of personal injury arising from a malfunction.

Due to the limited space in this paper, the artifactsshown in this case study represent only a small subsetof the overall system model. However, they nicelyillustrate the application of our integrated modelingapproach and its suitability for the development ofsafety-critical systems.

4.1 System Structure and Behavior

Since we are describing the system architectureon a very abstract level, a plain UML componentdiagram provides appropriate expressive capabilitiesto describe the system structural domain for thiscase study. Figure 3 gives a high-level architectureoverview for the gas heating boiler of our examplesystem. Such a model can be derived at early designstages, as soon as the operational context of thesystems has been determined.

Figure 3: Architecture of the gas heating system.

We use UML state machines to model thebehavior of the burner controller, which monitorsand controls the combustion of natural gas insidethe burner. As an example, Figure 4 describes themain operating states of the burner controller, whichcan be either operational or shut down in case amalfunction of the flame supervision mechanism hasbeen detected.


164

Figure 4: Behavior model of the burner control logic.

4.2 Reliability Model

An early step during development of a safety-criticalsystem is the assessment of potential hazards and riskassociated with the system under development (seesection 7.4 of IEC 61508-1:2010 (2010) for details).This hazard and risk assessment, performed by ateam of domain experts, can be documented in a riskassessment model.

Based on this initial assessment, mitigationmeasures are defined for safety-relevant hazards todetermine the necessary risk reduction to achieve atolerable risk. A Fault Tree Analysis (FTA) canbe carried out to quantitatively determine the actuallikelihood for a given hazard based on the hazardassessment and the proposed levels of protection.

As an illustrative example, we have chosen toanalyze a potentially hazardous failure of the heatingsystem, namely the presence of uncombusted gasin the burner chamber following a flameout. Thissituation can lead to rupture of the heating vesseldue to over-pressurization or rapid deflagration orexplosion of the uncombusted gas in the presence ofan igniting spark. Both hazards are assumed to occurwith an intolerably high likelihood, which promptsthe addition of a flame detection mechanism andan automatic safety shutdown valve to the heatingsystem.

Figure 5 shows the fault tree model for thishazardous event, highlighting the two componentsof the analysis: the root causes for the hazardousevent, and the simultaneous failure of protectivesafety functions. Note that all basic events can befurther developed – the fault tree has been truncatedto fit the scope of the use case.

Figure 5: Fault tree model for hazardous eventUncombusted Gas after Burner Flameout.

4.3 Requirements Model

Based on an annotation of the acceptable risktarget for the hazardous event in the model andthe occurrence likelihood of the root causes for theflameout (calculated through an architecture analyis),our framework can identify necessary safety functionand allocate safety integrity levels to them (seesections 7.5 and 7.6 of IEC 61508-1:2010 (2010) forthe regulatory background).

Figure 6 shows a part of the safety requirementsmodel for the previously discussed risk ofuncombusted gas. A safety function with a specifiedsafety integrity level is required to mitigate this risk,and is allocated to a system component, namely theburner controller.

Figure 6: Safety requirements model.


165

Note, that besides this domain-specific model ofsafety requirements, a complete integrated systemmodel of the gas heating would also contain allfunctional requirements that govern the regularoperation of the system.

4.4 Integration Model

The integration model for our use case ties togetherthe system structure and behavioral domain, withall additional domain-specific models regarding thereliability of the heating system.

We can see from Figure 7 that the integrationmodel forms a hierarchy of abstract componentswith the entire system under development at its root.Furthermore, the IM reflects the allocation of abstractfunctionality, e.g. the logic of the burner controller, tocomponents and contains traceability information intothe concrete behavioral model. In our example, theintegration model associates the state machine for theburner control (see Figure 4) with the abstract controllogic functionality.

Figure 7: Excerpt from Integration Model with links to SSDand SBD.

Beyond this abstract description of the systembehavior and structure, the integration model playsa crucial role for maintaining the consistency ofthe reliability model. By establishing a linkbetween identified hazards, failure events in faulttree models, and the associated system components(as seen in Figure 8), the IM forms the basisfor the integrated consideration of reliability andrisk management activities during the design ofthe heating system. Based on this information,accompanying documentation can be generated to beused as evidence in safety certification of the burnercontrol system.

Figure 8: Excerpt from Integration Model with links forreliability model.

5 RELATED WORK

Our work relates to previous research in threerelated, but separate fields: Firstly, our approachprovides a means of integrating various engineeringdisciplines into a coherent tool environment.Each of these disciplines brings with it its ownset of domain-specific engineering artifacts andmodeling languages. Finally, our implementationof an architecture analysis framework based on anintegrated system model relates to prior work in thefield of model-based analysis.

The following sections give a short overview ofthe relevant literature in these three fields, as theyrelated to our current research.

5.1 Modeling Tool Integration

In his seminal work, Wasserman (1990) describesan approach for integration of heterogeneous toolsin a software engineering tool chain. He describesan integrated software engineering framework basedon three cardinal dimensions of interoperability –presentation, data, and platform integration.

The EU-funded iFEST project (IndustrialFramework for Embedded Systems Tools1) wasaimed at developing an integrated framework forembedded systems, addressing both software andhardware concerns. The iFEST approach specifiesa tool integration framework that leverages theOSLC specification to allow data exchange betweenheterogeneous modeling tools. Since it is focusedexclusively on the aspect of tool integration, thisapproach does not address the field of model-basedanalyses of the integrated system model.

5.2 Domain-specific Modeling

Zschaler et al. (2009) proposes a generalization ofDSLs to domain-specific modeling languages, in

1http://www.artemis-ifest.eu/


166

order to capture common concepts found in familiesof related DSLs and facilitate automation.

Similarly, de Lara et al. (2015) describean approach for domain-specific multi-levelmetamodeling languages, allowing for the definitionof deep language hierarchies. Their approachcontains a set of reusable metamodel transformationsfor management of multi-level metamodelinglanguages and describes approaches for codegeneration in such a setting.

The use of UML as a graphical visualizationlanguage for domain-specific modeling languagesis proposed by Graaf and van Deursen (2007).Their work proposes model-to-model transformationsas a means of deriving a visual representationfrom a domain-specific model. Conceptually, thesetransformations can be regarded as an embedding ofthe DSML into a generic-purpose modeling language,namely into UML.

5.3 Model-based Analysis

Papadopoulos and McDermid (1999) introduceHiP-HOPS (Hierarchically Performed HazardOrigin and Propagation Studies), a methodologyfor model-based hierarchical reliability analysisof component-based systems. Based on thearchitecture of the system under analysis andcertain failure annotations, HiP-HOPS allows forbottom-up generation of Fault Trees and so-calledinterface-focused FMEA results for a system.Under the HiP-HOPS methodology, components areaugmented with additional model information abouttheir failure behavior. Various classes of interfacefailures are defined, that can be used to describe theblack-box failure model of a system on a componentlevel.

This approach has subsequently been extendedto accommodate aspects of automatic architectureoptimization. Papadopoulos et al. (2010) describesa conceptual approach for the automatic allocation ofsafety integrity levels to components of safety-criticalsystems. This work is focused on the automotivedomain and uses the EAST-ADL2 modeling languagefor architecture description. Similarly, Papadopouloset al. (2011) proposes a more generic architectureoptimization approach based on the HiP-HOPSmethodology and the use of genetic algorithms.

A complementary approach can be found in theEU-funded MBAT project (Combined Model-basedAnalysis and Testing of Embedded Systems2).This project aimed to provide a methodology andtechnology platform for specification of system

2http://www.mbat-artemis.eu/

analysis and V&V activities in the context ofembedded system engineering. The central elementof the proposed methodology is the so-called A&Tmodel (short for [static] analysis and [model-based]testing), highlighting the focus of the approach to thequality-assurance domain.

6 CONCLUSIONS

We have proposed a valuable approach for integratedsystem modeling and model-based architectureanalysis.

Our work introduces a solution to the challenge ofintegrating both system modeling and quality-relatedartifacts in the design and implementation ofembedded systems. The resulting integrated systemmodel or Omni model establishes explicit traceabilitybetween domain-specific modeling artifacts andenables consistent change management and changeimpact analyses.

Based on this holistic, model-based viewon the entire system under development,purpose-specific textual artifacts can be generated inan automated fashion through the use of model-to-texttransformations.

We have developed a reference technologyplatform that combines this integrated systemmodeling approach with a model-based analysisframework. The suitability of this prototype isdemonstrated through a case study, which illustratesthe use of the framework to model the reliabilityaspects of a residential gas heating burner, a simplesafety-critical embedded system.

Future Work

While our technology prototype has shown thefeasibility of our theoretical approach, we see severalpossible fields for improvement and extension of thearchitecture and analysis framework:

In order to reduce the need for re-creation ofexisting domain-specific modeling artifacts inside ageneral-purpose modeling tool, existing modelingtools can be integrated by means of a technologyintegration bridge. OSLC3 (Open Services forLifecycle Collaboration) and ModelBus4 are twosuitable candidates for such an integration platform.Both aim to provide heterogeneous tool integrationthrough open, web-based technologies and could beused to establish transparent traceability between our

3http://www.open-services.net4http://www.modelbus.org


167

proposed integration model and models distributedacross one or more domain-specific tools. Figure 2illustrates the addition of OSLC and/or ModelBusto our reference technology platform as part of themodel-based analysis framework.

A similar argument can be made for a moregeneric access to a shared model repository.Currently, our prototype shares a relational databasefor the integrated system model with the proprietaryEnterprise Architect model repository. ModelBus,with its integrated model repository component (seeHein et al. (2009), section 2), can help to reduce thistight coupling between the generic persistence layerand a single modeling tool.

Besides the technical improvements, we foresee aworthwhile extension of our modeling approach withaspects of contract-based design. Since our integratedsystem model already encompasses comprehensiveinformation about non-functional aspects of thesystem under development, this knowledge canbe used to derive constraints and guarantees forsystem components. The automated nature of ouranalysis framework allows for design optimizationbased on domain-specific models. Information aboutcomponent prerequisites and guarantees in the formof contracts can be used to reduce the complexity ofthe design space during such automatic architectureoptimization.

ACKNOWLEDGEMENTS

The research in this paper was funded by theGerman Federal Ministry for Economic Affairs andEnergy under the Central Innovation Program forSMEs (ZIM), grant numbers KF 2751303LT4 and16KN044120.

REFERENCES

de Lara, J., Guerra, E., and Cuadrado, J. S. (2015).Model-driven engineering with domain-specificmeta-modelling languages. Software & SystemsModeling, 14(1):429–459.

Graaf, B. and van Deursen, A. (2007). Visualisationof domain-specific modelling languages using uml.In 14th Annual IEEE International Conference andWorkshops on the Engineering of Computer-BasedSystems (ECBS’07), pages 586–595. IEEE.

Hein, C., Ritter, T., and Wagner, M. (2009). Model-driventool integration with modelbus. In Workshop FutureTrends of Model-Driven Development, pages 50–52.

IEC 61508-1:2010 (2010). Functional safety ofelectrical/electronic/programmable electronic

safety-related systems - Part 1: General requirements.Standard, International Electrotechnical Commission,Geneva, CH.

Kaiser, B., Liggesmeyer, P., and Mäckel, O. (2003). A newcomponent concept for fault trees. In Proceedings ofthe 8th Australian workshop on Safety critical systemsand software-Volume 33, pages 37–46. AustralianComputer Society, Inc.

Kelly, T. and Weaver, R. (2004). The Goal StructuringNotation–A Safety Argument Notation. In Proc. ofDependable Systems and Networks 2004 Workshop onAssurance Cases.

Kurtev, I. (2007). State of the art of QVT: Amodel transformation language standard. InInternational Symposium on Applications of GraphTransformations with Industrial Relevance, pages377–393. Springer.

OMG QVT v1.3 (2016). Meta Object Facility (MOF) 2.0Query/View/Transformation Specification, Version1.3. Specification, Object Management Group(OMG), Needham, MA.

OMG REQIF v1.2 (2016). Requirements InterchangeFormat (ReqIF), Version 1.2. Specification, ObjectManagement Group (OMG), Needham, MA.

Papadopoulos, Y. et al. (2010). Automatic allocationof safety integrity levels. In Proceedings of the1st workshop on critical automotive applications:robustness & safety, pages 7–10. ACM.

Papadopoulos, Y. et al. (2011). Engineering failure analysisand design optimisation with HiP-HOPS. EngineeringFailure Analysis, 18(2):590–608.

Papadopoulos, Y. and McDermid, J. A. (1999).Hierarchically performed hazard origin andpropagation studies. In International Conferenceon Computer Safety, Reliability, and Security, pages139–152. Springer.

Saad, C. and Bauer, B. (2013). Data-Flow BasedModel Analysis and Its Applications, pages 707–723.Springer Berlin Heidelberg, Berlin, Heidelberg.

Schleicher, A. and Westfechtel, B. (2001). Beyondstereotyping: Metamodeling approaches for theUML. In Proceedings of the 34th Annual HawaiiInternational Conference on System Sciences, page 10pp. IEEE.

Sommerville, I. (2011). Software Engineering. PearsonEducation, 9th edition.

Vesely, W. E., Goldberg, F. F., Roberts, N. H., and Haasl,D. F. (1981). Fault tree handbook. Technical report,DTIC Document.

Wasserman, A. I. (1990). Tool integration in softwareengineering environments. In Software EngineeringEnvironments, pages 137–149. Springer.

Zschaler, S., Kolovos, D. S., Drivalos, N., Paige, R. F., andRashid, A. (2009). Domain-specific metamodellinglanguages for software language engineering. InInternational Conference on Software LanguageEngineering, pages 334–353. Springer.


168

a domain-aware framework for integrated model-based system ... · a domain-aware framework for...

Documents