Model-based analysis support for dependable complex systems in CHESS

Felicien Ihirwe1, Silvia Mazzini1, Pierluigi Pierini1, Stefano Tonetta2 and Alberto Debiasi21Innovation Technology Service Lab, Intecs Solution Spa, Pisa, Italy

2Embedded Systems Unit, Fondazione Bruno Kessler (FBK), Povo, Italy{felicien.ihirwe,silvia.mazzini,pierluigi.pierini}@intecs.it, {adebiasi,tonettas}@fbk.eu

Keywords: CHESS, model driven engineering, complex systems, dependability analysis

Abstract: The challenges related to dependable complex systems are heterogeneous and involve different aspects of thesystem. On one hand, the decision-making processes need to take into account many options. On the otherhand, the design of the system logical architecture must consider various dependability concerns such as safety,reliability, and security. Moreover, in case of high-assurance systems, the analysis of such concerns must beperformed with rigorous methods. In this paper, we present the new development of CHESS, a cross-domain,model-driven, component-based and open-source tool for the development of high-integrity systems. We focuson the new recently distributed version of CHESS, which supports extended model-based development andanalyses for safety and security concerns. Finally, we present contributions of CHESS to several internationalresearch projects.

1 INTRODUCTION

The ever increasing complexity and dependabilityissues of systems in various domains, such as trans-portation, space, energy, health, and industrial pro-duction, requires effective design and developmentmethods. The complexity and heterogeneity of com-ponents requires modeling approaches that spans dif-ferent technical disciplines and prove effective in theend-to-end engineering of the products. This im-ply taking into account various requirements such asquality, performance, cost, safety, security, and reli-ability. Model-based design technologies enable theuser to perform beforehand different assurance relatedactivities such as physical architecture exploration,system’s behavioral analysis, early verification, andvalidation.

CHESS (Cicchetti et al., 2012) toolset offers across-domain modeling and analysis of high-integritysystems providing an integrated framework that helpsthe modeler (user) to automate different developmentphases: from the requirements definition, to the archi-tectural modeling of the system’s software and hard-ware, up to its deployment to hardware platform (Ci-cchetti et al., 2012). CHESS follows a component-based approach where the user decouple differentfunctional parts of the system as components that canbe modeled, analyzed, verified, stored, reused indi-vidually, and be integrated to meet the system’s com-

mon goal. CHESS supports, among other, schedu-lability and dependability analysis across the entireprojects life cycle. The results of the analysis areback-propagated to the model itself so that the mod-eler can review and fine-tune the model to satisfyreal-time and dependability requirements (Puri et al.,2020).

CHESS recently became a full-fledged open-source project, hosted by The Eclipse Foundation(https://www.eclipse.org/chess/). The code is de-veloped by various contributors following an open-source approach with public projects for issue track-ing, code repository branches, and continuous inte-gration. This paper presents the latest developmentof CHESS to address software’s security and safetyanalysis of the system exploiting the CHESS errormodel to represent faults and attacks. Analysis iscompleted by the integration with back-end tools suchas xSAP (Bittner et al., 2016) and Mobius (Court-ney et al., 2009) for the minimal cut sets analysis andMonte-Carlo simulation.

We report on various projects that used CHESS toprovide evidence for the assurance of complex sys-tems and on the functionalities that have been addedfor such purpose. So far CHESS has been appliedin domains such as Avionics (Godard and Nelissen,2016), Automotive (Bressan et al., 2018), Space (Paceet al., 2014), Telecommunication (Mazzini, 2015),and Petroleum (Gallina et al., 2014)(Montecchi and

arX

iv:2

009.

0608

9v2

[cs

.SE

] 1

3 N

ov 2

020

Gallina, 2017).The rest of the paper is arranged into six sections.

Sections 2 provides an introduction to the CHESS toolbuilding blocks and methodology, Section 3 presentsthe new major features released under CHESS 1.0.0,Section 4 presents some practical applications on dif-ferent projects, Section 5 discusses the related workwith respect to CHESS approach. In Section 6 wepresent the envisioned future extension on CHESSand finally Section 7 concludes the paper.

2 CHESS IN A NUTSHELL

The CHESS modeling tool was released under theEclipse PolarSys project1 and recently it was movedfrom the incubation status to the first major release.CHESSML is an integrated modelling language pro-filed from OMG standard languages: UML, SysMLand MARTE under the Papyrus modeling environ-ment (Papyrus, 2020). Figure 1 shows the high-levelarchitecture of CHESS infrastructure. Not all the fea-tures from all the three languages were used, CHESSonly exploits specific subsets of the them that suitsits perspective. There are different tools, plugins, andlanguages that were integrated into CHESS to sup-port model validation, model checking, realtime anddependability analysis.

Figure 1: CHESS high level structure

In this section, we are going to look at differentcore aspects of CHESS methodology, developmentfeatures, and implementation mechanisms. We willalso look in depth at different analysis mechanismsthat are being performed in CHESS and how they linktogether to enhance system correctness.

1https://projects.eclipse.org/projects/polarsys.chess

2.1 Component-based methodology

CHESSML language supports a component-baseddevelopment methodology. Emphasis is given toseparation of concerns between the functional andthe non-functional dimensions, such as safety, secu-rity, reliability, performance, and robustness (Mazziniet al., 2015).

In CHESS, components at design level encompassfunctional concerns only (i.e., they are devoid of anyconstructs pertaining to tasking and specific compu-tational model). The specification of non-functionalattributes is then used for the automated generationof the container, enforcing the realization of the non-functional attributes declared for the component to bewrapped.

This CHESS component-based approach enforcestwo main aspects of modeling: “Compositionality”and “Composability”. Compositionality implies thatall the properties of the whole system are determinedas the collection of the properties of the constitutingcomponents and its execution environment. Compos-ability is achieved when the individual components’properties are preserved from its definition, develop-ment, and deployment on the target platform (Mazz-ini et al., 2015). These two component’s propertiesare conceived through the whole development processto support the “composition with guarantee” property,which in turn, gets verified through analysis results.

The CHESS methodology follows the “Correct-ness by Construction” practice which enforces (1) theuse of formal and precise tools and notations for thedevelopment and the verification of all product items;(2) say things only once to avoid contradictions andrepetitions; (3) the design of software componentsthat are easy to verify, by e.g., using safer languagesubsets, and to implement, by using appropriate cod-ing styles and design patterns. (Panunzio and Var-danega, 2014).

2.2 Multi-view modeling approach

The CHESS tool provides a set of design viewsto uphold the ”separation of concern”, the ”correct-ness by construction” and the other methodologicalprinciples introduced before. Six main views (re-quirement, component, system, deployment, analy-sis and instance views) are defined to support TheCHESS modeling approach. Throughout the develop-ment process, each view has its own underlined con-straints that enforce its specific privileges on modelentities and properties that can be manipulated. De-pending on the current stage of the design process,CHESS sub-views are adopted to enhance certain de-

sign properties or stages of the process. Figure 2shows the high level architecture of CHESS views andtheir inter-relations.

2.2.1 Requirement view

Originally adopted from the SysML requirementdiagram, the requirement view is used to define sys-tem requirements and track their verification. InCHESS, requirements are part of the model and play acentral role in the system development life cycle. Thesystem elements are associated with the technical re-quirements they satisfy, which are, in turn, traced tohigher-level requirements, up to system-level require-ments (Mazzini et al., 2015). This association tech-nique enhances the traceability while evaluating thecorrectness and consistency of the modeled system.In this way, the change’s impact can be better evalu-ated and faithful model verification evidence can beprovided according to the requirements.

2.2.2 System view

It provides a suitable frame for system-level de-sign activities. In the System view, the system en-tities are initially designed into blocks and then hi-erarchically decomposed. The system view sup-ports contract-based design and several functionaland dependability analysis. CHESSML inherits fromSysML the specification of the block hierarchies andtheir internal decomposition, i.e. a block definitiondiagram can describe a system structure by means ofa set of blocks and each block may have its own dedi-cated internal block diagram describing its sub-blocksdecomposition and interfaces.

2.2.3 Component view

This view is used for software design work andlogic of the intended model. The component view iscomposed of two sub-views, Functional View whichis enabled by default, and the Extra-Functional Viewwhich is enabled manually in the tool. The Func-tional View is used to model system functional spec-ifications using diagrams such as class, compositestructure, state machine, activity, and sequence di-agrams. On the other hand, the Extra-FunctionalView is used to compose the system’s extra-functionalspecifications such as the real-time and dependabil-ity attributes. Recall that all views have a dedicatedpalette depending on their requirements, for instance,the extra-functional view has no access to the activitydiagram and has the palette with entries exclusivelyrelated to extra-functional concerns.

2.2.4 Deployment view

This view is used to model for software design thehardware structure of the system and permits the al-location of their corresponding software componentinstances. Through the use of class and compositestructure diagrams, the user can model the type ofdeployment on either single or multi-core processor.In this view, each hardware resource is allocated toa specific memory partition and can only access andchange its own memory space. Regarding the soft-ware to hardware resources allocation, all softwarecomponents are allocated to cores.

2.2.5 Analysis view

This is used to capture all the activities and di-agrams related to analysis in CHESS. The analysesperformed in CHESS are real-time analysis, quantita-tive dependability analysis, failure propagation anal-ysis, and so on. We will discuss further on analysis insection 2.3.

2.2.6 Instance view

CHESS provides a dedicated view to visualize andmodel the Platform Specific Model (PSM) as a com-bination of hardware and software instances gener-ated from the deployment and component views re-spectively through the composite structure diagrams.This is a novel approach to facilitate the analysis be-tween model instances. These instances are automat-ically generated when the BuildInstance command isinvoked. In the generated instance model each com-ponent’s property and connector are mapped onto adedicated InstanceSpecification.

2.3 Model-based Analysis andverification

CHESS provides the capability to perform severalkinds of analysis depending on the specific require-ments (functional, timing, dependability). Many ofthese functionalities have been added to the new re-lease of CHESS and are further explained in the nextsection.

Functional Verification by means of modelchecking is supported by the integrated nuXmv modelchecker (Cavada et al., 2014). System and componentproperties, derived from requirements, can be formal-ized into linear temporal logic properties, then theycan be verified on top of the system’s or component’sbehavioral models developed using state machines.

Figure 2: CHESS views architecture,

Contract-Based Analysis is built on top of theOCRA tool support (Cimatti et al., 2013). Compo-nent formal properties are structured in terms of con-tracts, comprised of an assumption and a guaranteepairs. The assumption is a restriction on the com-ponent’s environment or usage, and the guarantee isa property that must be satisfied by the component -provided that the environment satisfies the assump-tion (Mazzini et al., 2016).

Timing Analysis is built on top of the MAST2

analysis tool. It is invoked to perform analysis suchas schedulability and end-to-end response time analy-sis. Schedulability analysis is performed by taking in-put from the annotated PSM model and the computedpartition schedule on each available processing unit.Then, the response-time analysis calculates the worst-case response time of each task(Godard and Nelissen,2016) assessing the schedulable tasks complying withthe given timing constraints. The end-to-end analysisis done by utilizing the component sequence diagram.Applying MARTE timing stereotypes, the tool evalu-ates the hardware component’s responsiveness. Thisanalysis facilitates “early end-to-end response time

2https://mast.unican.es/

verification”, giving a sense of any possible refine-ment of the model before deployment (Mazzini et al.,2015).

Model validation exploits several types of meth-ods to assess the software system on its target plat-form. We can mention: (1) Model core constraintsvalidation is performed to enforce the CHESS modelconstraints including specific preconditions as re-quired by the schedulability analysis. (2) Validatemodel for state-based analysis, (3) Validate modelfor model checking, (4) Validate model for criticalityspecification and finally (5) Validate model for Auto-motive 26262 compliance (only specific for automo-tive domain) checks the system correctness of Auto-motive Safety Integrity Level(ASIL) inheritance anddecomposition according to the ISO 26262 standard.

3 NEW SYSTEM-LEVELANALYSIS SUPPORT

In this section, we present the new major fea-tures released in CHESS 1.0.0. The new release in-cludes the extension support for system-level safety

and security analysis. CHESSML dependability pro-file which normally supports different techniques forsafety and dependability analysis has been extendedto model fault injection and threats. Other new fea-tures include contract validations, parameter-basedarchitectures, and document generation. This newrelease can be accessed at https://www.eclipse.org/chess/

3.1 Fault Injection and Model-BasedSafety Analysis with xSAP

The new release supports the conduct of FaultTree Analysis (FTA) and Fault Mode Effect Analy-sis (FMEA). FTA is a deductive technique for identi-fying, evaluating, and modeling the interrelationshipbetween events leading to a failure or an undesiredstate. FMEA is a highly structured approach throughwhich all potential failure modes of a system and theireffects can be identified, evaluated, and prioritized(Bozzano and Villafiorita, 2013).

Once the system model is defined in CHESS,through components definition and their nominalbehavioral model, the faulty behavior is expressedthrough a specific state machine called ”ErrorModel”. The Error Model extends the nominal statemachine with information about the effect upon aproperty of the component, and consequently on itsnominal behavior. The next figure represents an ex-ample of an error model that, in case of an inter-nal fault, moves the related component in an errorstate where the property ”energy” is stuck at 0 value.The optional probability assigned to that transition is5x10−2. Once the error model is defined, the FTA or

Figure 3: State machine modeling faulty behavior

FMEA can be done by invoking the xSAP symbolicmodel checker through the CHESS environment.

The xSAP approach is based on the library-basedfault injection (i.e., an extension of a behavioralmodel with the definition of faults taken from a li-brary of faults) and the use of model-based routinesto generate safety artifacts.

The result of the FTA is the fault tree that is au-tomatically shown in a dedicated panel in the front-

end; see Figure 3 for an example. If fault probabil-ities have been specified during the configuration ofthe error model, the fault tree will report their com-bination. The fault tree can be examined for theminimal cut-set, identifying the basic fault conditionswhich can lead to the top-level failure. This is ad-

Figure 4: A fault tree visualized in the CHESS Editor View;note the probabilities associated to the top and basic events

ditional to the already existing analysis techniquesin CHESS such as Failure Logic Analysis (CHESS-FLA) (Gallina et al., 2014) and State Based Quantita-tive Dependability Analysis (CHESS-SBA) (Montec-chi et al., 2013).

3.2 Reliability Analysis with Mobius

Mobius3 is a software tool for modeling the be-havior of complex systems, by allowing the studyof the reliability, availability, security, and perfor-mance for large-scale discrete-event systems (Court-ney et al., 2009). Many reliability analysis resultscan be obtained with probabilistic models built withMobius using the stochastic activity networks (SAN)formalism, solved via Monte-Carlo simulation4. TheCHESS profile for dependability is used to enrichfunctional models of the system with information re-garding the behavior with respect to faults and fail-ures, thus allowing properties like reliability, avail-ability, and safety to be documented and analyzed.

The new release supports the modeling of secu-rity concerns which helps in threat identification at

3https://www.mobius.illinois.edu/4https://www.investopedia.com/terms/m/

montecarlosimulation.asp

the early stages of the development and facilitates theexploiting of the Mobius capabilities for analysis ofreliability. Specific extensions are related to the mod-elling of Cyber-Attacks aspects and models transfor-mations from CHESS to the Mobius tool to run theanalysis of SANs.

As a results the implemented a methodology al-lows modeling of a system security threat and a datacorruption threat, which may result in a service cor-ruption. An example of a system security threat canbe a cyber-security attack, i.e. an unauthorized accessof the system, halting services. Figure 5 depict the

Figure 5: Process of Security breach

process of a security breach that leads to the viola-tion of the security-related properties. A threat event,initiated by a threat source agent, able to exploit avulnerability of an asset (e.g. a component/system)may result in a loss to the confidentiality, integrity,and/or availability of the asset. Vulnerabilities couldbe represented as a pre-defined enumeration collectedthrough different sources (e.g. personal competence,standards, results of previous threat analysis, etc.). Fi-nally, the consequences could be modeled using pre-defined effects, which refers to the loss of Confiden-tiality, Integrity and Availability (CIA).

Figure 6: Erroneous state transition due to security threatevent and vulnerability

An <<ErrorModel>>-tagged state machine isused when modeling the security breach. The fail-ure, internal fault, and effect are extended to includesecurity threats, vulnerability, and consequences re-spectively. Figure 6 illustrates an example of an er-ror model, where a cyber-security attack initiates adata corruption threat. The vulnerability was mod-eled exploiting the value check function which is setto false. In this case, the system transits to an erro-

neous state leading to component failure. Note that acomponent could have multiple instances of <<Er-rorModel>>-tagged state machines, attached to it.Each instance would provide the elaboration of in-put/output failure behavior addressing a specific con-cern.

The generation of the Mobius SAN model pro-cess is done by performing an automatic model-to-model transformation from a model instance to theSAN model recognized by Mobius for reliability anal-ysis.

The new release facilitates the exploiting of theMobius analysis capabilities for safety and securityco-engineering needs, according to the scenario ad-dressed envisaged in (Popov, 2017). Editing Mobiusmodels cannot be trivial. To this purpose we have ex-tended the CHESS profile and therefore the CHESSmodelling language capabilities and user-friendly ed-itor as front-end to fully support the modelling of sys-tem architectures taking in consideration safety andsecurity co-engineering, and using automatic trans-formations to SAN model for reliability analysis withMOBIUS. This approach provides a smooth inte-gration, guarantees the consistency among SysMLand SAN models, and drastically reduce the effortrequired to construct an appropriate SAN analysismodel.

This extension has been developed in the contextof the AQUAS project, as result of a collaborative ef-fort among Intecs and City University of London, andapplied across different use cases, in the ATM and In-dustrial Drive domain.

3.3 Improved support forcontract-based design analysis andmodel checking

In the contract-based paradigm, the properties ofeach component may be restricted to its interfaces.The contracts are pairs of properties representing anassumption and a guarantee of the component. In ad-dition, CHESS tool supports the contract refinementanalysis for composite components. The contract ofa composite component is defined by the assumptionof the composite component itself and the guaranteeensured by the contracts of its sub-components, con-sidering their interconnection as described by the ar-chitecture and and that the assumption of each sub-component is ensured by the contracts of the othersibling sub-components.

The new CHESS release has improved thecontract-based analysis aspects by integrating CHESSwith V&V tools such as OCRA, nuXmv, and xSAP.In this regard, the new additional analysis includes:

(1) Model checking, i.e. the behavioral models,that describe how the internal state of a componentand the output ports are updated, can be verifiedagainst some formal properties in different temporallogics. The formal properties can represent some re-quirements (e.g., functional or safety-related require-ments) or some validation queries such as the reacha-bility of states.

(2) Contract-based compositional verification ofstate machines is performed on composite com-ponents. The local state machine of each sub-component is verified separately against its local con-tract. The correctness of the composite componentis implicitly derived by the correctness of the con-tract refinement and the successful verification of lo-cal state machines.

(3) Contract-based safety analysis, i.e. identifythe component failures as the failure of its implemen-tation in satisfying the contract. When the componentis composite, its failures can be caused by a failureof one or more sub-components and/or a failure ofthe environment in satisfying the assumption. As re-sult, the analysis produces a fault tree in which eachintermediate event represents the failure of a compo-nent or its environment, linked to a Boolean combina-tion of other nodes. The top-level event is the failureof the system component. The basic events are thefailures of the leaf sub-components, in addition to thefailure of the environment (see (Bozzano et al., 2014)for more details).

3.4 Support for parameterizedarchitecture and trade-off analysis

In a parameterized architecture the number ofcomponents, the number of ports, the connections,and the static attributes of components depends ona (possibly infinite) set of parameters. In the newrelease, it is possible to define a parameterized ar-chitecture, setting the multiplicity of FlowPorts andsub-components to express a list of elements with thesame type. This can be very helpful when model-ing a system with a large number of similar nodes.The modeling of the parameterized architecture is fol-lowed by its instantiation. In this phase the user setsthe values of the parameters, defining the configu-ration of the architecture. OCRA takes in input theparameterized architecture and one or more configu-rations. Then, OCRA produces the instances of thearchitecture, and for each of them, performs a listof contract-based verifications. The output is the re-sult derived from the contract-based verifications de-scribed in Section3.3.

This new release also supports Tradeoff analysis

which allows to execute a certain check such as safety,security, performance analysis on selected configura-tions (instances) and get the results in a view that sim-plifies the comparison between them. This makes iteasy to visually get an idea of how the intended modelinstances perform with respect to the selected config-urations. Figure 7 shows the sample result of a trade-

Figure 7: Trade-off Analysis results sample

off analysis made on two instances by looking at dif-ferent concerns specified by the assumption/guaranteeformal properties of each contract.

3.5 Automatic generation of diagramsand documentation

The traditional way of editing a model is byadding an element in a diagram but changes madein the model are not reflected in the diagrams. Thenew CHESS release offers the possibility of generat-ing a diagram from the model which reflects the datain the model on the fly. The supported diagrams areBlock Definition Diagram(BDD) and Internal Blockdiagram(IBD). Multiple diagrams can be generatedon a single component in the model. The generateddiagram elements will be automatically aligned butthe user can rearrange by moving elements manuallyor by invoking “layout selection command.”

The new release also supports the generation ofthe model architecture and the report on various anal-yses executed on the model in an HTML document ora LaTeX source code. The report is divided into twosections. The first describes the structure of the modelwhich includes diagrams and the associated compo-nents while the second includes the report lists of theresults of the validation and verification (V&V) anal-yses results. There are many types of V&V resultssuch as property validation, assume/guarantee prop-erties results, contract checks results, model checking,FTA, FMEA, and so on. Figure 8 gives the sample ofthe report page that can be generated by the tool.

4 CHESS TOOL IN PRACTICE

Throughout different phases of extending CHESS,CHESS was involved in many projects, research com-munities, and academies. CHESS has been usedfor teaching and extending it for research purposes.

Figure 8: Generated report sample

CHESS has conducted more than 10 internationalrecognized research and development projects in theframe of 8 years5. Following we list a brief extent onthe projects through which the CHESS tool played amajor role.

4.1 ARTEMIS JU-CHESS

ARTEMIS JU-CHESS6 is the originating projectthat developed the CHESS tool. The project aimedto improve model-driven engineering practices andtechnologies to better address safety, reliability, per-formance, robustness, and other non-functional con-cerns. This was achieved while guaranteeing the cor-rectness and composition of components under de-velopment in the embedded systems domain. Fromthis point, the various project was initiated to extendCHESS to a new level by adding more functionalitiesand incorporate other domains.

4.2 CONCERTO

CONCERTO7 project aimed to deliver a referencemulti-domain architectural framework for complex,highly concurrent, and multi-core systems, wherenon-functional properties (including real-time, de-

5https://projects.eclipse.org/projects/polarsys.chess/releases/1.0.0/review

6http://www.chess-project.org/7http://www.concerto-project.org/

Figure 9: The main workflow supported by CHESS inAMASS

pendability, and energy management) was establishedfor individual components. CONCERTO frameworkwas built on top of the CHESS framework developedin 4.1, as well as the results of several other relatedprojects. The project enforced the modeling of multi-core processors among the possible target platforms,with the same level of correctness and guarantees asfor traditional single-core processor targets (Baracchiet al., 2016).

4.3 AMASS

AMASS8 (Architecture-driven, Multi-concernand Seamless Assurance and Certification of Cyber-Physical Systems) project aim was to create and con-solidate the de-facto European-wide open tool plat-form, ecosystem, and self-sustainable community forassurance and certification of Cyber-Physical Sys-tems (CPS) in the largest industrial vertical mar-kets (Alana and Herrero, 2018). In this project,CHESS played a role in system architecture modelingassurance, patterns library management assurances,contract-based assurances, and verification and val-idation (V&V) based assurances through its exten-sion with some tools such as OCRA, nuXmv, andxSAP. For future consultation, the contributor offersfree training accessible at https://www.amass-ecsel.eu/content/training which includes video tutorials anddocumentation. Figure 9 shows the main workflowsupported by CHESS in the context of AMASS. Theworkflow included the definition of the system andtheir formal requirements, the functional refinementof the system, the definition of the nominal and faultybehaviors, and finally, the safety analysis.

8https://www.amass-ecsel.eu/

4.4 AQUAS

AQUAS9(Aggregated Quality Assurance in Sys-tems) project aims was to improve on how the non-functional requirements of safety, security, perfor-mance (SSP) are dealt with during the product lifecycle for embedded computer systems. AQUAS ap-proach was based on two main principles. First, applythe methods for combined analyses of project artifactsfrom the viewpoints of safety, security, performance.Second, limit the overhead cost of these combinedanalyses by only applying them at a limited numberof points in the product life-cycle, called interactionpoints (Popov et al., 2020).

The main CHESS’s contribution to the project wasto support the modeling of the software architecture ofthe several use cases. CHESS was used to enrich thesystem and software architecture model with informa-tion related to safety, security and performance co-engineering, and support of automated toolchains andtraceability for combined analysis among the prod-uct. In particular, the tool was used to perform per-formance analysis and support dependability analy-ses with SANs, exploiting new capabilities presentedin section 3.2.

4.5 SESAMO

SESAMO10 project aimed to develop a methodol-ogy to reduce interdependencies between safety andsecurity mechanisms. This was achieved by con-structing a tool-chain that uses the constructive ele-ments and integrated analysis procedures to ensurethe safety and security characteristics of the sys-tem are maintained. The CHESS contribution to theproject was (1) the introduction of the concept ofcomponents and reusability into the modelling pro-cess. (2) the definition of safety and security as non-functional properties, within the CHESS componentmodel perspective. (3) provide separation of con-cerns for the modelling of safety and security in asingle model enabling joint verification and analysis(SESAMO, 2014).

4.6 MEGAMART

MegaM@Rt11 is an open-sourced project with theambition to create a framework which incorporatemethods and tools for continuous development andvalidation. This project leverages the advantages inscalable model-based methods to provide benefits in

9https://aquas-project.eu/10http://sesamo-project.eu/11https://megamart2-ecsel.eu/

significantly improved productivity, quality, and pre-dictability of large and complex industrial systems.Employing its rich model-driven toolchain, CHESS

Figure 10: CHESS fit in MegaM@Rt Tekne case study

served in the design and the development of high-integrity systems with a focus on non-functional prop-erties(Afzal et al., 2018). In this project, CHESSwas used in the design and analysis of the Teknecase study. This was an ultra-wideband (UWB) mo-bile network technology with a short-range commu-nication, indoor positioning, and tracking capabilities(Cruz et al., 2020).

Figure 10 shows the process of modeling theTekne case study. In this project, requirement mod-eling, traceability, contract-based design approach,component real-time behavior analysis exploit anddemonstrate the CHESS potential. In addition, thecollected run-time logs were analyzed by CHESS tocapture non-functional constraint violations. The re-sults are back-propagated to the design environmentfor further model refinement (Cruz et al., 2020).

5 RELATED WORK

Several commercial tools provide similar func-tionalities of CHESS. One of the most popular isMatlab/Simulink(Mathwork, 2020). Although Mat-lab/Simulink facilitates the modelling and analysis ofcomplex systems, its simulation efficiency might bean important disadvantage. Being based on a singleModel of Computation and Communication (MoCC)is another limitation. CoFluent is another commer-cial tool extended to model IoT systems (Intel, 2020).Although supporting more interaction models thanMatlab/Simulink, it is also limited in the way com-

ponents may interact among them.Another tendency is to overcome the UML lacks

in semantic content, required in some applicationdomains, towards a proliferation of DSLs (Bram-billa et al., 2012). Among the available DSLs,UML/MARTE is the standard language for real-timeand embedded systems design, while SysML is thestandard language for system modeling. Several mod-elling environments like Papyrus (Papyrus, 2020)support UML/MARTE. Nevertheless, its flexibilityand semantic richness requires the definition of effi-cient modelling methodologies.

Capella (Capella, 2020) is an open-source com-prehensive and extensible Eclipse system modellingtool. It is inspired to the SysML principles and itsupports the ARCADIA methodology that is success-fully deployed in a wide variety of industrial contexts(Bonnet et al., 2015). ARCADIA provides architec-tural descriptions for functional analysis, structuralanalysis, interfaces and behavior modeling, structuredin five perspectives according to major system engi-neering activities and concerns.

COMPASS (Bozzano et al., 2019) supportsmodel checking, model-based safety, reliability, andperformance analysis and shares with CHESS someof the tools used as backend for such analyses. Differ-ently from CHESS, it targets a variant of AADL anddoes not support traceability and code generation.

MapleSim12 is a modeling tool for multi-domainengineering systems built on top of Modelica mod-eling language (Elmqvist et al., 1998). MapleSimfeatures an integrated environment in which the sys-tem equations can be automatically generated and an-alyzed (Cao and Wu, 2013).

Although we see some approaches able to tacklemodeling challenges, no tool or approach has beenable to fit in our methodology with such analysis andverification functionalities. Which makes CHESS anovel approach for implementing component-basedmodeling methodology for real-time and dependablesystems by taking care of non-functional propertiesand enforces the correctness at all the stages of thedevelopment process.

6 FUTURE WORK

CHESS is a very huge toolset with more sophisti-cated and powerful functionality to meet user needs.However, there is still a gap for improvement, to covermore and more domains such as the Internet of Things(IoT) in a more concrete way. Note that we are not

12https://www.maplesoft.com/products/maplesim/

concluding that it is not capable to perform some ba-sic modeling of IoT related scenarios but we aspireto make it more IoT specific. This extension will fol-low CHESS’s component-based methodology and itwill also follow already existing modeling approachespresent in CHESS.

The envisioned approach will be achieved by im-proving the CHESSML metamodel with a set of spe-cific stereotypes, contracts, communications, and op-erations profiled for IoT. The new proposed approachwill also take in use of already existing dependabil-ity analysis infrastructure such as Fault Mode EffectAnalysis, Fault Logic Analysis, Fault Tree Analysis,and so on. We also plan to export IoT models devel-oped with CHESS to external consumers. Finally, weplan to exploit the current CHESS’s code generationsupport for Ada language, integrated with the open-source ThingML framework, for IoT code generation.

7 CONCLUSIONS

Dependable complex system design and devel-opment present several challenges, the well-knowncanonical approach is to divide complex systems intosmaller chunks (or subsystems), build them sepa-rately, and later integrate them. In this paper, wepresented the current state of the CHESS tool totackle design, analysis, and verification of real-timedependable complex systems. We walked throughthe CHESS tool architecture and we highlightedits component-based and multi-view modeling ap-proaches. We have also presented the new system-level extensions and capabilities of the tool releasedunder the CHESS1.0.0 version. Finally, we intro-duced the different projects and contributions whereCHESS was used either in the industry and academiaat large and presented the future envisioned extensionstrategy.

ACKNOWLEDGEMENTS

This work has received funding from the Low-comote project under European Union’s Horizon2020 research and innovation program under theMarie Skłodowska-Curie grant agreement n813884.We would like to acknowledge also differentprojects funding leading to the mature realization ofCHESS which include the CHESS13, CONCERTO14,

13http://www.chess-project.org/14http://www.concerto-project.org/

SESAMO15 under ARTEMIS Joint Undertaking ini-tiative, and AMASS16, and AQUAS17 under EC-SEL Joint Undertaking initiative. We would liketo acknowledge the main contributors to the devel-opment of the CHESS toolset, in particular StefanoPuri, Nicholas Pacini, Luca Cristoforetti and PietroBraghieri. Finally, we would like to acknowledge alsoProf. Davide Di Ruscio for the assistance on draftingthis paper.

REFERENCES

Afzal, W., Bruneliere, H., Di Ruscio, D., Sadovykh,A., Mazzini, S., Cariou, E., Truscan, D., Cabot,J., Gomez, A., Gorronogoitia, J., Pomante, L., andSmrz, P. (2018). The MegaM@Rt2 ECSEL project:MegaModelling at Runtime – Scalable model-basedframework for continuous development and run-time validation of complex systems. Microproces-sors and Microsystems: Embedded Hardware Design(MICPRO), 61:86 – 95.

Alana, E. and Herrero, J. (2018). Design and safety as-sessment of on-board software applications using theamass platform. In EUROSPACE DASIA 2018.

Baracchi, L., Mazzini, S., Puri, S., and Vardanega,T. (2016). Lessons learned in a journey towardcorrect-by-construction model-based development. InBertogna, M., Pinho, L. M., and Quinones, E., ed-itors, Reliable Software Technologies – Ada-Europe2016, pages 113–128, Cham. Springer InternationalPublishing.

Bittner, B., Bozzano, M., Cavada, R., Cimatti, A., Gario,M., Griggio, A., Mattarei, C., Micheli, A., andZampedri, G. (2016). The xSAP Safety Analysis Plat-form. In Chechik, M. and Raskin, J., editors, Toolsand Algorithms for the Construction and Analysisof Systems - 22nd International Conference, TACAS2016, Held as Part of the European Joint Conferenceson Theory and Practice of Software, ETAPS 2016,Eindhoven, The Netherlands, April 2-8, 2016, Pro-ceedings, volume 9636 of Lecture Notes in ComputerScience, pages 533–539. Springer.

Bonnet, S., Voirin, J.-L., Normand, V., and Exertier, D.(2015). Implementing the mbse cultural change: Or-ganization, coaching and lessons learned. INCOSEInternational Symposium, 25(1):508–523.

Bozzano, M., Bruintjes, H., Cimatti, A., Katoen, J., Noll,T., and Tonetta, S. (2019). COMPASS 3.0. In Vojnar,T. and Zhang, L., editors, Tools and Algorithms for theConstruction and Analysis of Systems - 25th Interna-tional Conference, TACAS 2019, Held as Part of theEuropean Joint Conferences on Theory and Practiceof Software, ETAPS 2019, Prague, Czech Republic,April 6-11, 2019, Proceedings, Part I, volume 11427

15http://sesamo-project.eu/16https://www.amass-ecsel.eu/17https://aquas-project.eu/

of Lecture Notes in Computer Science, pages 379–385. Springer.

Bozzano, M., Cimatti, A., Mattarei, C., and Tonetta, S.(2014). Formal safety assessment via contract-baseddesign. In International Symposium on AutomatedTechnology for Verification and Analysis, pages 81–97. Springer.

Bozzano, M. and Villafiorita, A. (2013). Safety critical sys-tems. In Encyclopedia of Software Engineering. CRCPress (Taylor & Francis Group).

Brambilla, M., Cabot, J., and Wimmer, M. (2012). Model-Driven Software Engineering in Practice, volume 1.

Bressan, L., de Oliveira, A. L., Montecchi, L., and Gallina,B. (2018). A systematic process for applying the chessmethodology in the creation of certifiable evidence. In2018 14th European Dependable Computing Confer-ence (EDCC), pages 49–56.

Cao, J. M. and Wu, T. (2013). Multi-domain modelingsimulation and application based on maplesim. InMechatronics and Intelligent Materials III, volume706 of Advanced Materials Research, pages 1894–1897. Trans Tech Publications Ltd.

Capella (2020). An open source solution for model-basedsystems engineering. Last Accessed: July 2020.

Cavada, R., Cimatti, A., Dorigatti, M., Griggio, A., Mar-iotti, A., Micheli, A., Mover, S., Roveri, M., andTonetta, S. (2014). The nuXmv Symbolic ModelChecker. In Biere, A. and Bloem, R., editors, Com-puter Aided Verification - 26th International Confer-ence, CAV 2014, Held as Part of the Vienna Summerof Logic, VSL 2014, Vienna, Austria, July 18-22, 2014.Proceedings, volume 8559 of Lecture Notes in Com-puter Science, pages 334–342. Springer.

Cicchetti, A., Ciccozzi, F., Mazzini, S., Puri, S., Panunzio,M., Zovi, A., and Vardanega, T. (2012). CHESS: amodel-driven engineering tool environment for aid-ing the development of complex industrial systems.In 2012 Proceedings of the 27th IEEE/ACM Interna-tional Conference on Automated Software Engineer-ing, pages 362–365.

Cimatti, A., Dorigatti, M., and Tonetta, S. (2013). OCRA:A tool for checking the refinement of temporal con-tracts. In Denney, E., Bultan, T., and Zeller, A., edi-tors, 2013 28th IEEE/ACM International Conferenceon Automated Software Engineering, ASE 2013, Sil-icon Valley, CA, USA, November 11-15, 2013, pages702–705. IEEE.

Courtney, T., Gaonkar, S., Keefe, K., Rozier, E. W. D., andSanders, W. H. (2009). Mobius 2.3: An extensibletool for dependability, security, and performance eval-uation of large and complex system models. In 2009IEEE/IFIP International Conference on DependableSystems Networks, pages 353–358.

Cruz, J. G., Sadovykh, A., Truscan, D., Bruneliere, H.,Pierini, P., and Muniz, L. L. (2020). Megam@rt2 euproject: Open source tools for mega-modelling at run-time of cpss. In Ivanov, V., Kruglov, A., Masyagin, S.,Sillitti, A., and Succi, G., editors, Open Source Sys-tems, pages 183–189, Cham. Springer InternationalPublishing.

Elmqvist, H., Mattsson, S. E., and Otter, M. (June, 1998).Modelica- the new object oriented modeling language.The 12th European Simulation Multiconference.

Gallina, B., Sefer, E., and Refsdal, A. (2014). To-wards safety risk assessment of socio-technical sys-tems via failure logic analysis. In 2014 IEEE Interna-tional Symposium on Software Reliability EngineeringWorkshops, pages 287–292.

Gallina, B., Sefer, E., and Refsdal, A. (2014). Towardssafety risk assessment of socio-technical systems viafailure logic analysis. In Proceedings of the 2014IEEE International Symposium on Software Reliabil-ity Engineering Workshops, pages 287–292.

Godard, W. and Nelissen, G. (2016). Model-based designand schedulability analysis for avionic applications onmulticore platforms. 37:157–163.

Intel, C. (2020). Solution for simulation and modeling ofsystems. Last Accessed: July 2020.

Mathwork (2020). Simulation and model-based design.Last Accessed: July 2020.

Mazzini, S. (2015). The concerto project: An open sourcemethodology for designing, deploying, and operat-ing reliable and safe cps systems. Ada User Journal,36:264–267.

Mazzini, S., Favaro, J., and Baracchi, L. (2015). A model-based approach across the IoT lifecycle for scalableand distributed smart applications. In 2015 IEEE 18thInternational Conference on Intelligent Transporta-tion Systems, pages 149–154.

Mazzini, S., Favaro, J. M., Puri, S., and Baracchi, L.(2016). CHESS: an open source methodology andtoolset for the development of critical systems. InEduSymp/OSS4MDE@MoDELS.

Montecchi, L. and Gallina, B. (2017). Safeconcert: Ametamodel for a concerted safety modeling of socio-technical systems. In Bozzano, M. and Papadopou-los, Y., editors, Model-Based Safety and Assessment,pages 129–144, Cham. Springer International Pub-lishing.

Montecchi, L., Lollini, P., and Bondavalli, A. (2013).A reusable modular toolchain for automated de-pendability evaluation. In Proceedings of the 7thInternational Conference on Performance Evalua-tion Methodologies and Tools, ValueTools ’13, page298–303, Brussels, BEL. ICST (Institute for Com-puter Sciences, Social-Informatics and Telecommuni-cations Engineering).

Pace, L., Pasquinelli, M., Gerbaz, D., Fuchs, J., Basso,V., Mazzini, S., Baracchi, L., Puri, S., Lassalle, M.,and Viitaniemi, J. (2014). Model-based approach forthe verification enhancement across the lifecycle of aspace system. In INCOSE Italian Chapter Conferenceon Systems Engineering (CIISE2014).

Panunzio, M. and Vardanega, T. (2014). A component-based process with separation of concerns for the de-velopment of embedded real-time software systems.Journal of Systems and Software, 96:105 – 121.

Papyrus (2020). Eclipse papyrus modeling environment.Last Accessed: July 2020.

Popov, P. (2017). Models of reliability of fault-tolerant soft-ware under cyber-attacks. In 2017 IEEE 28th Interna-tional Symposium on Software Reliability Engineering(ISSRE), pages 228–239.

Popov, P., Strigini, L., Hunt, S., and et al (2020). Deliver-able 3.3: Combined analysis of safety, security andperformance. Technical report, City, University ofLondon and AQUAS team.

Puri, S., Mazzini, S., and Pachini, N. (May 2020). CHESStoolset user guide, toolset release 1.0.0.

SESAMO, T. (2014). D4.2 – Integrated Design and Evalu-ation Methodology Version 01.