A Process-oriented Build Tool for Safety-critical Model-based Software

Development

Markus Hochstrasser

, Stephan Myschik

and Florian Holzapfel

Institute of Flight System Dynamics, TU M

unchen, Boltzmannstraße 15, 85748 Garching, Germany

Chair of Flight Mechanics and Flight Control, Universit

at der Bundeswehr M

unchen,

Werner-Heisenberg-Weg 39, 85577 Neubiberg, Germany

Keywords:

Build Automation, Workﬂow Management System, Component-based Software Engineering, Software

Development Process, Model Standards, Model Scaffolding, Continuous Integration.

Abstract:

By conquering new application areas, software complexity and size increases steadily. Development cycles

must become faster to deliver critical updates in shorter time. Simultaneously, software takes over more and

more safety-critical tasks, requiring strict software development processes. Up to today, these processes suffer

from extensive manual review work and written, static documentation in form of standards, checklists, and

procedures. This paper presents a monolithic, process-oriented build tool for model-based development in

MATLAB, Simulink, and Stateﬂow. Beyond classical build automation functionality, it supports and acce-

lerates process workﬂows. The tool provides infrastructure to formalize and ship workﬂows, checklists, and

standards, but also features to assess completeness, consistency, compliance, and cleanliness with respect to

them. Additionally, it allows deﬁnition of dynamic, incrementally updated checklists, and composes tracea-

bility in parallel with the build. The efﬁcacy and achievable process coverage is demonstrated in an example

application.

1 INTRODUCTION

With increasing requirements for automatic and au-

tonomous functionality, software development faces

new challenges concerning implementation and veri-

ﬁcation techniques. Algorithms rapidly grow in size

and complexity (Basagiannis, 2016). At the same

time, software has to fulﬁll higher safety and secu-

rity standards due to the evolved tasks they take over.

Besides, software development not only gets larger, it

also becomes faster. With new software trends, like

connected or cloud-based algorithms, software deve-

lopment life cycles have to accelerate drastically. In-

creased vulnerability of systems requires to deliver

new software releases more frequently.

To handle complexity and accelerate deve-

lopment, the transition from classical to model-

based or even model-driven software development

(MBD/MDD) is a step, which many companies have

already taken over the last years. It comes along with

enormous cost and time savings, but requires elabo-

rate model-based development “and an established

development process” (Broy et al., 2014) as well as

a high degree of scalability and automation of tasks

to fulﬁll objectives (Bhatt et al., 2010).

By developing ﬂight control algorithms for safety-

critical applications for years, the Institute of Flight

System Dynamics at TU M

unchen has gathered broad

experience concerning MBD with MATLAB, Simu-

link, and Stateﬂow

(Hornauer and Holzapfel, 2011;

Hornauer et al., 2013; Hochstrasser et al., 2016; Ho-

chstrasser et al., 2017), especially in the context of

DO-178C/DO-331 (RTCA, 2011a; RTCA, 2011c).

Thereby, a gap between process planning and its

realization could be observed, contradicting the de-

manded high degree of automation in MBD.

Process engineering meta models like SPEM 2.0

(OMG Object Management Group, 2008) help to de-

ﬁne a process, activities, and artefacts on a planning

level (cf. (Gallina, 2014)), but engineers must manu-

ally identify the tasks to execute and how to execute

them. If the planning documentation is too detailed,

developers are overwhelmed by the details. If it is too

abstract, the space for interpretation is too large. In

both cases, deviations from the intended planning are

very likely.

Furthermore, it is difﬁcult to communicate a pro-

Product of MathWorks Inc. for model-based simulation

and software development

Hochstrasser, M., Myschik, S. and Holzapfel, F.

A Process-oriented Build Tool for Safety-critical Model-based Software Development.

DOI: 10.5220/0006605301910202

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 191-202

ISBN: 978-989-758-283-7

191

cess setup to developers in a way, in which they can

efﬁciently apply it. In consequence, developers st-

ruggle with the tool complexity

. A process setup

for MATLAB, Simulink, and Stateﬂow may contain a

whole modeling environment with conﬁguration set-

tings and customizations (Hochstrasser et al., 2017;

Estrada et al., 2013; Dillaber et al., 2010), but also

more process-related information, like modeling ru-

les, procedures for the analyses to execute and re-

views to perform (cf. reference workﬂows addres-

sed by (Marques et al., 2012; Potter, 2012; Erkinnen

and Potter, 2009; Conrad et al., 2012; Conrad et al.,

2009)).

Assessment of process compliance, consistency,

and cleanliness of the software project, especially af-

ter changes, is still manual work and linked to enor-

mous effort. Every tool has its own report format and

justiﬁcation workﬂow. Model reviews are intensively

used by a majority of companies (Broy et al., 2014),

but sophisticated tool support is missing.

Last but not least, the provided traceability in

MBD approaches is too weak to perform serious im-

pact analysis. Neither veriﬁcation arefacts like reports

are typically included, nor is it granular enough (Paz

and El Boussaidi, 2016).

The proposed solution for these challenges is a

process-oriented build tool, speciﬁcally designed for

MBD in high-integrity applications. In general, build

tools allow modeling of a dependency network of

tasks and their execution in an ordered and optimi-

zed way (cf. (Humble and Farley, 2015; Berglund

and McCullough, 2011; Sonatype Company, 2008)).

Core idea and contribution of this paper is to enhance

and adopt known basic build tool capabilities. The

introduced term process-oriented emphasizes on the

one hand the interaction with a traceability graph in

contrast to task- and product-oriented tools (Humble

and Farley, 2015). On the other hand, features are

added to improve process compliance, guidance, and

the resolution of the previously stated challenges in a

safety-critical context.

Section 2 introduces the generic workﬂow suppor-

ted by the tool, followed by a more detailed discussion

of the tool capabilities in Section 3. Section 4 presents

selected insights into traceability management and the

underlying data model. Afterwards, Section 5 outli-

nes an example implementation highlighting the rea-

chable process coverage. In Section 6, existing tools

and solutions are discussed and differences to the pre-

Reith Graham, 2015, Adoption of Model-Driven

Engineering in Small Workgroups and in Large Organi-

sations, https://nmi.org.uk/wp-content/uploads/2015/06/

MathWorks-Adoption-of-Model-Driven-Engineering.pdf

[Accessed on 2017/27/10]

sented tool are revealed. Limitations and an outlook

of future work are ﬁnally given in Section 7, before

the results are summarized in Section 8.

The presented tool has originally been created to

support a MBD workﬂow fulﬁlling objectives of DO-

178C/DO-331 in accordance with the MathWorks re-

ference workﬂow (The MathWorks Inc., 2016a) (Re-

lease 2016b). Anyway, it is customizable for every

process in MATLAB and not limited to the use in a

DO-178C process.

2 WORKFLOW OVERVIEW

Recent studies showed that build tools are well accep-

ted, if they do not hinder usual work style, are custo-

mizable, and ﬁt into workﬂows (Rahman et al., 2017).

Thus, an important aspect of the presented tool is to

accompany the whole workﬂow, but at the same time

allow developers using existing, familiar routines.

Figure 1 depicts a typical MBD change workﬂow

as it is often pursued. Involved are three roles, a Pro-

cess Manager, a Developer, and an Assessor. Develo-

per and Assessor may be the same person depending

on the required independence of the process. Not con-

sidered for simplicity is independent testing.

Process

Manager

Developer

Assessor

Define /

change

process and

process setup

Perfrom

change impact

analyis

Implement

model and

apply process

Build code,

verification

artefacts,..

Review compliance,

consistency,

completeness, and

cleanliness

Perform

review and

justify

(Commit/Handoff

for analysis/review)

Defect/

Req.

Change

(1)

(2) (3) (4)

(5) (6)

Planning

& Process Setup

Design

& Build

Review

Figure 1: Traditional change workﬂow.

Most processes start with an intensive planning

phase, in which the Process Manager, who is respon-

sible for the planning and tools, sets up and docu-

ments a tool chain, tool conﬁguration, modeling ru-

les, activities, and checklists to fulﬁll the objectives

imposed by the respective development standard (1).

The plans, standards, and setup are passed to a Deve-

loper, who reads and applies it during implementation

(3). In case of a change, impact analysis may be per-

formed prior to the actual modiﬁcation of the design

(2). As soon as the model has been updated, code ge-

neration and veriﬁcation tasks are executed to create

needed artefacts (4). In all cases, identiﬁcation of im-

pacted ﬁles is a manual and error-prone task, since

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

192

appropriate tools and traces are often missing. Fi-

nally, the module is handed over to an Assessor for

analysis and review (5 and 6). Again, extensive ma-

nual work is required to check, if reports ﬁt to the

latest model version and checklists must be reevalu-

ated step by step. Justiﬁcations are typically distri-

buted over different reports or even embedded in the

models, which often leads to problems with not mat-

ching revision numbers. All steps (1-6) require fully

initialized models in a running MATLAB instance.

This very generic process is supported by the build

tool in different ways and can be leveraged with a

CI system as drafted in Figure 2. An environment

to formalize and wrap procedures or checklists into a

dynamic build workﬂow and to create rapid scaffol-

ding plugins is provided to the Process Manager as

further described in Section 3.1 (1). The formalized

setup is passed to the Developer, who can integrate

it into his software modules. After that, the tool ex-

poses several automatic and semi-automatic methods

to rapidly scaffold the software model according to

standards and guidelines (3). This accelerates model

creation and leads to models, which are compliant to

standards by construction. Traceability information

of a previous build can be accessed via a web inter-

face and is useful to estimate the impact of a change

in advance (2).

As soon as the design is ﬁnished, pre-deﬁned build

jobs (e.g., code generation or analysis jobs on mo-

del and code) can be executed incrementally based on

modiﬁcations and their dependencies (4). Along with

the build, the tool automatically creates and maintains

detailed traceability. This close interaction between

build steps and traceability is a key aspect of the tool,

as it relieves developers from manually updating tra-

ceability information. The build not only supports

fully automatic tasks, but can also be used to generate

dynamic checklists, which beneﬁt from incremental

change detection and impact recognition in the back-

ground, too.

The changed software module is submitted to the

version control system and a connected CI system au-

tomatically checks, if the minimum requirements for

a successful build are fulﬁlled and the stored build in-

formation is up-to-date (5). If this is the case, a ma-

nual reviewer can access the build information via a

web interface and review or justify the results without

changing existing artefacts (6). Additional review in-

formation is also submitted and again checked by the

CI system, whether it fulﬁlls approval requirements

(e.g., if all warnings are justiﬁed).

CI System

Process

Manager

Developer

Assessor

Define / change

process and

formalize

process setup

Perfrom

change impact

analyis

(web-based UI)

Implement

model with

model

scaffolding

Incrementally

build code,

verification

artefacts,..

Perform review

and justify in

central UI

(web-based)

Commit

Defect/

Req.

Change

(1)

(2) (3) (4)

(5)

(6)

Planning

& Process Setup

Design

& Build

Review

Fulfills minimum

requirements?

Fulfills approval

requirements?

Check

e.g., missing,

suspected,

or failure

e.g.,

unjustified

warning

Figure 2: Change workﬂow with build tool support and CI

system.

3 SUPPORTING TOOL

FEATURES

The previous section gave a brief overview of the pro-

cess. In this section, the different phases are addres-

sed in detail.

3.1 Planning

In the Planning Phase, the Process Manager trans-

forms written rules and procedures into a so-called

Life Cycle Package. The Life Cycle Package is a

combination of XML speciﬁcation, MATLAB clas-

ses, and resources of a full modeling environment

(Hochstrasser et al., 2017). It provides the blueprint

for model scaffolding (cf. Section 3.2.3) and the build

workﬂow. Life Cycle Packages are separate reposito-

ries in the version control system and thus fully inde-

pendent from the software modules managed by the

Developer.

Software modules are self-contained parts of the

software with artefacts passing the development and

veriﬁcation process together. Typically, different soft-

ware modules are maintained by different developers.

Here, any module at least consists of a single Simu-

link Projects

instance and a XML module descrip-

tion. The XML description is the basic information

source of the module and deﬁnes a unique ID, a name

of the module, other module dependencies that shall

be loaded, and the Life Cycle Package that applies to

Simulink Projects is a MathWorks toolbox

for team collaboration and to manage models,

https://nl.mathworks.com/discovery/simulink-projects.html

[Accessed on 2017/07/28]

A Process-oriented Build Tool for Safety-critical Model-based Software Development

193

the module.

3.2 Design and Build

If a Life Cycle Package is linked to the software mo-

dule, the Developer can use design and build functio-

nality, which is organized along stages as depicted in

Figure 3. These stages must be accessed sequentially,

since, in contrast to common source code build tools,

MATLAB and Simulink require initialized data, ob-

jects, and further artefacts in memory. The next secti-

ons traverse along the build workﬂow of Figure 3.

INIT

DESIGN

BUILD

POST-

BUILD

• Traceability impact analysis

• Module cleanup

• Incremental execution of post-

design build jobs

• Auto-initialization of Simulink data

• Incremental execution of pre-

design build jobs

• Creation and update of new

model elements (scaffolding)

• Synchronization between in-

memory objects and files

(OPTIONAL)

DEPENDENCY

INTEGRATION

• Integration of Life Cycle Package

and other module dependencies

from version control system

• Version conflict detection

Figure 3: Fix workﬂow stages and provided functionality.

3.2.1 Life Cycle Package and Dependency

Integration Stage

Prior to any implementation work, the tool supports

integration of other modules and automatic detection

of nested modules, so-called transitive dependency

resolution. Thereby, version conﬂicts are detected and

reported. Depending on the Life Cycle Package con-

ﬁguration, integrated dependencies may be initialized

differently than the current working module, for ex-

ample with regard to the set search path

The search path speciﬁes a set of folders where MAT-

LAB looks for ﬁles, classes, functions, and so on. Typically

it is updated once during initialization of a model, but in

some cases it is reasonable to update paths during build.

The build tool provides features to do this in a controlled

way and in connection with the build workﬂow.

3.2.2 INIT Stage

The INIT stage loads the Life Cycle Packages, sets

up search paths and auto-initializes all captured arte-

facts of the current and linked modules automatically.

Build jobs, which must be executed prior to design

stage can be hooked into this stage, too (cf. Section

3.2.4). This is beneﬁcial, if, for example, the software

environment shall be checked or customizations shall

be registered in Simulink in advance and the result

shall be documented.

3.2.3 DESIGN Stage

In the DESIGN stage, the Developer actually chan-

ges the model, simulation test cases, or requirement

linking. The workﬂows are basically unconstrained

in this stage, but support is given with the so-called

model scaffolding.

Many tasks, like writing initialization scripts or

saving objects as ﬁles, are time-consuming, error-

prone, and regularly repeated by every developer. In

addition, extensive modeling rules are most often han-

ded over as sole textual descriptions, in the best case

in combination with model checks that can evaluate,

whether the rules have been followed or not

. But ﬁn-

ding the textual guidelines of interest for the various

conﬁgurations that the MATLAB and Simulink envi-

ronment provides is cumbersome, and iterating to a

compliant model using model checks is a reverse and

time-wasting workﬂow.

A related problem appeared some years ago in

the web development domain, where every develo-

per built his web platform from the scratch. This led

to signiﬁcant overhead by repeating tasks and secu-

rity issues due to bad conﬁgurations. In 2004, Da-

vid Heinemeier Hansson presented “Ruby on Rails”

(Ruby, 2016), a web development framework based

on the principles “Don’t Repeat Yourself” and “Con-

vention over Conﬁguration (CoC)”. The idea behind

the principle CoC is reducing a set of conﬁgurati-

ons to a smaller set of conventions. In most cases,

it is sufﬁcient for developers to learn the conventions

without caring about the conﬁguration behind. “The

Convention over Conﬁguration pattern rewards deve-

lopers for adhering to naming conventions and enfor-

ces this in a stricter manner by building it into the

framework”

Jaffry, David, 2014, http://de.mathworks.com/comp

any/ newsletters/articles/best-practices-for-implementing-

modeling-guidelines-in-simulink.html [Accessed on

2017/27/07]

Chen, Nicolas, 2006, http://softwareengineering.vazex

qi.com/ﬁles/pattern.html [Accessed on 2017/12/07]

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

194

The build tool adopts this pattern to reduce manual

conﬁguration work with model scaffolding provided

to the user as command-line tool. To deﬁne conventi-

ons, the Process Manager customizes pre-deﬁned ab-

stract classes and formalizes information about folder

structure, modeling elements, and tool settings. The

Developer is then supported in

• creating new software modules, their structure,

and conﬁgured Simulink Projects as deﬁned by

guidelines,

• initialization of data from ﬁles (auto-initialization

without custom init scripts),

• creating models and related data in compliance

with guidelines and standards, as well as remo-

ving them, and

• synchronization between initialization scripts and

in-memory data of Simulink (e.g., buses in Simu-

link workspaces).

For example, the Process Manager deﬁnes the

conﬁguration for a special type of Simulink Bus,

which is imported from existing C header ﬁles and

thus does not have to be auto-generated. The type

of bus is registered in the build tool Life Cycle

Package as bus-imported together with the informa-

tion that any object name shall follow the expression

<module-id> <busname> Bus. As a consequence,

the tool automatically assumes that initialization

scripts are stored in a folder called bus/imported

with the ﬁlename pattern

<module-id> <busname> Bus init.m and registers

helpful commands, like

create bus-imported <busname>

to create a fully conﬁgured parameter in the Simulink

workspace, together with an initialization script.

The scaffolding interface imposes restrictions on

the user, like storing ﬁles at a speciﬁc location or

using pre-deﬁned formats, but all modules created

this way have the same look and feel and already com-

ply with standards by construction for the most part.

3.2.4 BUILD Stage

After ﬁnishing the design change, the Developer en-

ters the BUILD stage to generate code, run analysis,

or generate review checklists.

The sequence of build jobs and their dependencies

must have been deﬁned within the Life Cycle Package

XML speciﬁcation in advance. Build jobs are de-

rived from an abstract base class handling a wide

range of operations silently in the background. They

can be executed iteratively for a set of artefacts re-

sulting from a user-deﬁned, programmable selection

rule. E.g., a static model analysis can be executed for

every model in the software module.

Every job iteration is executed incrementally, me-

aning that inputs and outputs are checked, whether

they are deprecated. Therefore, meta information of

input and output artefacts is stored after each execu-

tion and compared to the currently available set of ar-

tefacts at a later point of time.

The build tool organizes jobs in an acyclic, di-

rected dependency graph. This allows the user to de-

ﬁne dependencies between jobs. Dependent jobs are

checked and re-executed prior to the called job in an

organized manner derived from the execution graph.

Beyond these functionalities, the interaction with

MATLAB during the execution must be emphasized.

A job can automatically record the command line out-

put and document thrown exceptions as well as war-

nings during build.

3.2.5 POST-BUILD Stage

The POST-BUILD stage presupposes, that all build

jobs have been executed at least once and traceability

has been established as far as possible. Basic inten-

tion of the POST-BUILD is to compose a single, ho-

listic artefact traceability tree and store it for future

impact analysis.

Besides, another addressed problem are dirty soft-

ware projects. Orphaned ﬁles and objects are of-

ten the result of modiﬁcations, renaming, or remai-

ning intermediate artefacts of the implementation. If

projects are not regularly cleaned up, unneeded ﬁles

accumulate and the question, whether a ﬁle is unne-

cessary and can be deleted or not, becomes harder and

harder to answer. Example applications with the build

tool showed that it is possible to generate a holistic

traceability graph containing meta data for all ﬁles

and objects that play any role in the module. Arte-

facts not appearing in this graph are suspected to have

no functionality. With the module cleanup feature,

the Developer can automatically identify orphaned ﬁ-

les and objects and delete them. This provides the

possibility to evaluate and enforce cleanliness.

3.3 Check and Review

The build tool can assess the status of a software mo-

dule. Such a scan is “silent”, it does not modify any

artefact of the module, but detects changes and out-

dated artefacts. The returned result is structured and

can easily be post-processed into the required format,

e.g., for CI Systems to accept or deny a commit into

version control.

The status of the build, job dependencies and the

whole traceability tree is stored in XML ﬁles and

A Process-oriented Build Tool for Safety-critical Model-based Software Development

195

is fully accessible without MATLAB and Simulink.

This independence may be the foundation for online

review processes, fully performed in the browser.

To display the results and go a ﬁrst step into this

direction, a web-based graphical user interface has

been created on top of the build tool as shown in Fi-

gure 4. It can directly interact with MATLAB and fe-

tch the latest status, but can also just read previously

updated status and traceability information. On the

left-hand side of the view in Figure 4, the status of

the build workﬂow is displayed for each phase and

job. Icons indicate the status. By clicking on the jobs,

further details are exposed on the middle panel. Be-

neath a general description, results are displayed for

each iteration of the job (task). The tool bar on the

right shows the dependencies and impact of the se-

lected task. In the given example, the selected task

fc AHRSVoter is deprecated, since the output report

does not match the underlying model anymore.

Module: fc_fl ig htcon trol

Analyze project

> CLEANUP

CleanCache

CleanCodeCache

> ENVCHECK

CheckSLECI

CheckBugFixes

VerifyMrailsVersions

> ENVSETUP

RegisterTargetInfo

SetFCCSampleTime

LoadSLCodingConfiguration

UpdateSLFileGenControl

SetupBlockLibrary

SetupModelAdvisor

SetupRMI

UpdateSharedCodeDir

> DESIGN-VERIFICATION

Compile

StaticModelAnalysis

DesignErrorDetection

ModelReview

> SIMULATION-TESTING

CompileTests

TestSimulation

> DESIGN-DEPLOY

Artifact Selection

task::mdl:\workspace\models_singleton\fc_AHRSVoter.slx

Artifact Filter

Uptrace

Downtrace

< REQUIRED BY

fc_AHRSVoter.c

< GENERATES

do331.jobs.GenerateCode.m

< GENERATES

fc_AHRSVoter

< REFERENCED_BY

config_settings

< INITIALIZES

fc_AHRSVoter.slx

< REFERENCED_BY

fsdlib

< REFERENCED_BY

fc_fcc_sample_time_d_s

< REFERENCED_BY

fc_p_z5x1

< IMPLEMENTED_BY

stanag4586-259

< IMPLEMENTED_BY

stanag4586-261

< IMPLEMENTED_BY

stanag4586-262

< IMPLEMENTED_BY

stanag4586-263

< REQUIRED BY

fc_AHRSVoter.h

< REQUIRED BY

fc_AHRSVoter_private.h

< REQUIRED BY

fc_AHRSVoter_types.h

< REQUIRED BY

do331.jobs.InspectCode.m

> GENERATES

fc_AHRSVoter_slci_report.html

> GENERATES

fc_AHRSVoter_slci_data.mat

> GENERATES

mrails-status.xml

> GENERATES

mrails-trace.xml

> GENERATES

log.txt

RescanBuildBuild (force)

InspectCode

Descriptio n

This job runs Simulink Code Inspector on the Source Code and the

Design Model. The job

clears existing result files.

is executed for every model in the containers "model-top",

"model-reusable", and "model-singleton".

distinguihses between model references and top-level models

during execution.

generates a HTML report.

The job analyzes Simulink Code Inspector results. The status is

PASS if

no error occurs during execution.

report and result data has been stored at the pre-defined

location.

the result of code inspection is "fully verified".

The status is FAIL otherwise.

DO-331 Objectives:

Table A-5: 1 Source code complies with low-level requirements.

Table A-5: 2 Source code complies with software architecture.

Table A-5: 5 Source code is traceable to low-level requirements.

Results

fc_actuatorLoop

fc_rolloff

fc_AHRSVoter

doFor Each

verif yFo rEach

fc_innerLoop

fc_outerLoop

fc_fcc

Figure 4: Graphical user interface of the build tool.

The user can drill into any job and get further in-

formation about the failure state or the nested status

structure. In Figure 5, for example, a missing bug ﬁx

on the host system has been detected during build. In

this case, it is classiﬁed as non-justiﬁable error and

may cause the CI system to deny a commit.

Execution Status

once

validateOnce

BugFix 1519083_16b_2017-01-11 is not installed correctly.

> PROJECT INFO

Dependencies

Artifact Tree

Traceability

> CLEANUP

CleanCache

CleanCodeCache

> ENVCHECK

CheckSLECI

CheckBugFixes

VerifyMrailsVersions

Figure 5: Detailed status information on an occurred build

error classiﬁed as non-justiﬁable.

In contrast to many common build tools, more ef-

fort has been spent on handling the return status in-

formation of jobs. The intention is to return not just

a pass or fail state, but to keep the result customiza-

ble. Ideally, the output of any other tool called by the

job is translated into the provided format. This way,

the build tool and its GUI become a unique place to

review the complete status of the project.

Therefore, the tool provides a status object, which

holds a general state (Figure 6) and detailed formatted

descriptions. Furthermore, the user can specify whet-

her the state can be mitigated by justiﬁcation or not,

and to which target state. By nesting status objects,

almost any output structure can be rebuilt. The status

object also indicates, whether a job is suspected or not

and aggregates status and the suspected state through

the whole status hierarchy.

Executed

& Up-to-date

Executed

& Suspected

Not executed

Nothing to

execute

Passed

Warning

Fail

Figure 6: Basic execution status types.

The status objects can also be used to create in-

teractive and dynamic check lists. Since the detailed

description can be formatted with plain HTML, and

the job execution has full access to all MATLAB, Si-

mulink, and Stateﬂow APIs, tailored and dynamic re-

view lists can be generated upon model information.

In Figure 5, a non-justiﬁable status information

has been introduced. Alternatively, Figure 7 shows

an exemplary interactive model review checklist, em-

bedded in the build workﬂow. In a ﬁrst run, checklist

items are marked with the status WARN. By manu-

ally ticking items and/or adding a justiﬁcation text,

the status can be mitigated to PASS or any other status

according to a speciﬁed mitigation rule. The checklist

in Figure 7 is dynamic and supports incremental de-

precation. The item “Model interfaces comply with

ICD” directly lists all relevant Inport and Outport mo-

del elements to be reviewed with a direct link into the

model elements.

The advantages of the tight integration with the

build tool are obvious. At ﬁrst, checklists can be cre-

ated iteratively for a set of artefacts (see also Section

3.2.4). The Assessor can go through the checklist of

every model step by step and check the items. Like

jobs, reviews can deprecate or get under suspicion if

upstream dependencies change. The user gets a seam-

less review interface containing both job results and

dynamic checklists in the end.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

196

RERUN | UPDATE

Disable Edit Review

Enable Edit Review

Execution Status

fc_AHRSVoter

doForEach

Correct version of dependent modules is u sed.

Check if the following modules have the correct version and nested modules do

not produce a version conflict.

Model interfaces comply with ICD.

Check if the interfaces of your the model comply with the datatype, size, and

name defined in the Interface Control Document (ICD).

Review Inports:

fc_AHRSVoter/AHRS1

fc_AHRSVoter/AHRS2

fc_AHRSVoter/AHRS3

fc_AHRSVoter/AHRS1_Valid

fc_AHRSVoter/AHRS2_Valid

fc_AHRSVoter/AHRS3_Valid

Review Outports:

fc_AHRSVoter/voted_fb

Requirements are linked correctly.

Check if all requirements are linked and the linked model elements fit to the

content of the requirement.

> PROJECT INFO

Dependencies

Artifact Tree

Traceability

> CLEANUP

CleanCache

CleanCodeCache

> ENVCHECK

CheckSLECI

CheckBugFixes

VerifyMrailsVersions

> ENVSETUP

RegisterTargetInfo

SetFCCSampleTime

LoadSLCodingConfiguration

UpdateSLFileGenControl

SetupBlockLibrary

SetupModelAdvisor

SetupRMI

UpdateSharedCodeDir

> DESIGN-VERIFICATION

Compile

StaticModelAnalysis

DesignErrorDetection

ModelReview

Figure 7: Exemplary model review checklist.

4 TECHNICAL CONCEPTS

4.1 Traceability

The traceability graph mentioned in the previous pa-

ragraph must be captured and maintained.

Traceability exists with various characteristics and

for different purposes. In its most general deﬁnition,

a trace is a triplet of elements. A source and target

artefact as well as a trace link in-between (Gotel et al.,

2012).

The main requirement for the traceability graph

maintained by the build tool is to keep it adaptable

to any custom Traceability Information Model (TIM,

ader et al., 2013)). Thus the tool only provides the

infrastructure to store, relate, update, and query meta

data of artefacts in a directed graph. The data model

itself is further discussed in Section 4.2.

With regard to this ﬂexibility, a trace can be deﬁ-

ned between any type of software artefact, from infor-

mal to formal (cf. (Seibel et al., 2012)), in-memory,

or on the ﬁle system. Also the type of link, by (Seibel

et al., 2012) and (Lochmann and Hessellund, 2009)

categorized under hard (explicit) references, soft (im-

plicit) references, and semantic connections, is unre-

stricted.

(Asuncion et al., 2010) distinguish between pro-

spective and retrospective approaches. Retrospective

traceability approaches derive traces from a set of

static software artefacts. Prospective methods up-

date traces during artefact generation or modiﬁcation.

They are tightly connected to a development environ-

ment or techniques (Seibel et al., 2012), like a model

transformation into source code. The method here re-

presents a prospective approach, since traces are mo-

diﬁed in situ with the build process.

The methods chosen to create traces are rule-

based techniques. They provide the most ﬂexibility

and can cope with the heterogeneity of artefacts (Zis-

man, 2012). Furthermore, these methods support the

deﬁnition of candidate traces, which are traces that

ﬁnally must exist but are not created yet. Rules are

either deﬁned when setting up the model scaffolding

interface or with the speciﬁcation of the job. In the lat-

ter case, the rules describe traceability creation, but at

the same time deﬁne inputs and outputs for the build.

This double function is one of the core principles,

since it reduces conﬁguration effort. Traceability and

the build process beneﬁt from each other.

Figure 8 illustrates the interaction between the

build process and the traceability graphs. Every build

run starts with a copy of the design tree, which is the

basis for the so-called execution tree. The design tree

is the output of model scaffolding. For every job, a

selection of artefacts to iterate on is determined. The

rules for the required inputs and expected outputs are

evaluated and created artefacts pushed into the job

tree. Then, the core function of the job (“do”) is exe-

cuted. After that, a recovery rule is optionally called

to get traces for artefacts, which are not easily predic-

table beforehand (like the output of the translation to

source code).

Design

Tree

Job A

Job B

(depends

on Job A)

select

Job

Tree

Execution

Tree

require Input

expect Output

[do]

recover Output

select

Job

Tree

require Input

expect Output

recover Output

[do]

Figure 8: Interaction between build jobs and traceability

trees.

The job trees are serialized, cached, and stored,

which allows independent and incremental job exe-

cution. The separate treatment also increases robust-

ness. In contrast, it comes along with larger memory

requirements. A full traceability tree is only available

in the end, when all job trees are merged to a single

tree (cf. Section 3.2.5).

The build tool itself provides the infrastructure to

capture traces. The algorithms for recovering or esta-

blishing traces are implemented when setting up the

A Process-oriented Build Tool for Safety-critical Model-based Software Development

197

Life Cycle Package. For the application example pre-

sented later on, various convenient APIs have been

be combined to obtain traces. Embedded Coder ge-

nerates traces between model and source code, Simu-

link provides built-in methods to identify variable de-

pendencies in models, and Simulink Projects offers

ﬁle dependency analysis. However, also every non-

MATLAB based algorithm can be included.

4.2 Data Model

To efﬁciently handle artefact meta data and traceabi-

lity graphs, an optimised data model is required. Es-

pecially the repeated calculation of revisions and the

high number of artifact trees must remain managea-

ble. The implementation consists of three core ele-

ments as shown in the UML diagram of Figure 9:

An Artefact Pool, multiple Artefact Trees, and Meta-

Artefacts.

Figure 9: UML class diagram of data model (simpliﬁed).

Meta-Artefacts are the core element. They store

(at minimum) a unique ID, a name, information about

existence, and the current revision. A Meta-Artefact

is not necessarily bound to a tangible software arte-

fact, but can be created for every element whose ex-

istence and revision can be identiﬁed. For example,

Meta-Artefacts may be created for different kinds of

ﬁles, like reports, scripts, or code, but also for ob-

jects in the memory of MATLAB, like Simulink Bu-

ses, Parameters, and even for model elements. Meta-

Artefacts do not need to relate to an existing artefact,

they can also represent a so-called candidate artefact,

which is expected to be generated after job execution.

A build scan, for example, can create such candidate

artefacts and show the user in advance, what is mis-

sing. Figure 9 gives an overview of the currently used

types of artefacts, which have a differing implemen-

tation to evaluate existence and revision.

All artefacts are managed in Artefact Pools, which

are collections of artefacts without relations between

artefacts. Main function of the pool is to centralize

access and checking for deprecation. Artifact Pools

ensure that artefact meta data is just computed once

per run (unless explicitly enforced otherwise).

Artefacts plus their trace links are organized in Ar-

tefact Trees. Each Artefact Tree consists of a set of

connected or unconnected directed graphs. It provi-

des efﬁcient methods to query artefacts with customi-

zed selectors, traverse the graphs, as well as serialize,

read, or reduce them to a Traceability Information

Model. Important is that Artefact Trees only orga-

nize the relations and do not store the Meta-Artefacts.

This keeps the graph algorithms slim and efﬁcient.

5 PROCESS COVERAGE

EXAMPLE

This section presents parts of an example applica-

tion to show the necessity and capabilities of the pre-

sented build tool approach. It covers activities of

a DO-178C/DO-331 process using a so-called De-

sign Model (Simulink and Stateﬂow model) to re-

place DO-178C Software Low-Level Requirements

and Software Architecture. The mapping of activi-

ties and tools is as proposed in the Model-Based De-

sign Workﬂow for DO-178C (The MathWorks Inc.,

2016a). The data bases on the DO-178C case study

performed by Bill Potter for an helicopter autopilot

Three build phases are hooked into the INIT stage,

being executed before the developer starts the de-

sign. They can be found in Figure 11 on the left-hand

side. The CLEANUP phase clears caches, the EN-

VCHECK phase analyses the software environment

and veriﬁes that required bug ﬁxes are installed. The

ENVSETUP updates Simulink default settings and

loads custom checks, libraries, or code.

In the DESIGN stage, scaffolding methods are

provided for the following model data: Simulink Bu-

ses (exported and imported), Simulink Parameters

(constants and data-items), Simulink Signals (global,

and model scope), Simulink Models (top-level, reusa-

ble, non-reusable), Libraries, and Enums.

After entering the BUILD stage, the phases and

jobs listed in Table 1 are available to the Develo-

per and Assessor, covering various DO-331 objecti-

ves. The DESIGN-VERIFICATION phase starts with

a compile, which is also used to determine depen-

dencies between models and model data. Subsequent

https://nl.mathworks.com/matlabcentral/ﬁleexchange/

56056-do178-case-study

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

198

phases analyse the model for standard compliance,

runtime errors, compliance to requirements, or co-

verage. In the next phases, the model is transformed

to C-Code and veriﬁed with traditional software ana-

lysis afterwards. Table 1 also indicates, how the tra-

ceability graph is updated using inputs and outputs of

the jobs. Execution of the build assembles traces as

superﬁcially described by the TIM in Figure 10.

Table 1: Example build workﬂow. Each job creates traces to

required inputs (R), expected outputs (E), or recovered out-

puts (RC)). Numbers behind job name indicate dependent

jobs, which must be executed beforehand.

Build Workﬂow R E RC

Design Veriﬁcation

(1) Compile x

(2) Model Compliance Checks (1) x x

(3) Design Error Detection (1) x x

(4) Model Review (1) x

Simulation Testing

(5) Compile Tests x

(6) Simulation Tests (5) x x

Design Deployment

(7) Unprotected Deployment (1) x x

(8) Protected Deployment (7) x x

Code Generation

(9) Shared Code Gen. (1) x x x

(10) Code Generation (9) x x x

Code Veriﬁcation

(11) Auto C. Review (10) x x

(12) Code Compliance Checks (10) x x

(13) Code Defect Analysis (10) x x

The ﬁnal workﬂow and the composed, holistic tra-

ceability tree is plotted in Figure 11. The graph is

arranged using hierarchical edge bundling (Holten,

2006), which positions artefacts depending on their

type in a circle. For this relatively small model and

the simpliﬁed workﬂow, the traceability tree consists

of 237 artefacts and 592 traces. The huge amount

of dependencies gives an impression of the effort to

maintain consistency between artefacts in a safety cri-

tical process. It can barely be managed by hand and

substantiates the need for an automated solution as

presented in this research.

6 RELATED WORK AND TOOLS

This section gives an overview of existing approa-

ches and related tools and works out the differences.

For the separate disciplines combined in the presented

tool, a variety of alternatives could be listed provi-

ding support in build automation, traceability, review,

and scaffolding. However, they rarely integrate with

MATLAB, Simulink, and Stateﬂow in the depth as the

RequirementRequirement

Requirement IDRequirement IDPSPS

Init/Setter FileInit/Setter File

File System LocationFile System LocationPSPS

Workspace Object

(Simulink.Bus, Simulink.Signal,

Simulink.Parameter, Enum,

Constant)

Workspace Object

(Simulink.Bus, Simulink.Signal,

Simulink.Parameter, Enum,

Constant)

Name (unique)Name (unique)PSPS

ModelModel

Name (unique)Name (unique)PSPS

Config SetConfig Set

Name (unique)Name (unique)PSPS

Test CaseTest Case

UUIDUUIDPSPS

Code FileCode File

File System LocationFile System LocationPSPS

LibraryLibrary

Name (unique)Name (unique)PSPS

Verification ReportVerification Report

File System LocationFile System LocationPSPS

verifies

Generated by

implements

references

initialized by

references

Tool Config FileTool Config File

File System LocationFile System LocationPSPS

Execution ScriptExecution Script

File System LocationFile System LocationPSPS

requires (any)

references

generated by (any)

relates to

Requirement Link FileRequirement Link File

File System LocationFile System LocationPSPS

initialized by

Test FileTest File

File System LocationFile System LocationPSPS

initialized by

Figure 10: Example Traceability Information Model (sim-

pliﬁed).

presented tool does, and no tool provides a similar se-

amless approach. In the following, some tools with

the largest overlap are discussed.

Traceability in the context of MBD is treated in

various research publications. Tools like Reqtify

Yakindu Traceability

provide powerful traceability

features, but are not integrated with build automation

and mainly focus on retrospective traceability cap-

ture.

Build tools like Apache Ant

, Apache Maven

or Gradle

are known among developers for years.

They can evaluate the up-to-dateness of jobs, incre-

mentally rerun jobs, and manage transitive software

dependencies. However, the traditional areas of ap-

plication of these tools are Java and C/C++ builds.

Model-based design, which comes along with new

challenges like inherent dependencies (Seibel et al.,

2010), is rarely supported. Furthermore, a strong bin-

ding and interaction with modeling and veriﬁcation

tools is necessary in the presented use case. The inte-

raction with a multi-functional traceability graph as

Traceability management tool of Dassault Systems,

https://www.3ds.com/products-services/catia/products/req

tify/ [Accessed on 2017/03/08]

Traceability management solution of itemis AG,

https://www.itemis.com/en/yakindu/traceability/ [Accessed

on 2017/03/08]

Apache Ant is a Java library to setup build processes,

http://ant.apache.org [Accessed on 2017/27/07]

Apache Maven is a project management and com-

prehension tool, https://maven.apache.org, [Accessed on

2017/07/27]

Gradle is a build management and automation tool,

https://gradle.org [Accessed on 2017/07/27]

A Process-oriented Build Tool for Safety-critical Model-based Software Development

199

mrails.jobs.CleanCache.m

mrails.jobs.CleanCodeCache.m

do331.jobs.CheckSLECI.m

do331.jobs.CheckBugFixes.m

mrails.jobs.VerifyMrailsVersions.m

do331.jobs.RegisterTargetInfo.m

do331.jobs.SetFCCSampleTime.m

do331.jobs.LoadSLCodingConfiguration.m

do331.jobs.UpdateSLFileGenControl.m

do331.jobs.SetupBl

ockLibrary.m

do331.jobs.SetupModelAdvisor.m

do331.jobs.SetupRMI.m

do331.jobs.UpdateSharedCodeDir.m

mrails.jobs.Compile.m

do331.jobs.GenerateSharedCode.m

do331.jobs.GenerateCode.m

do331.jobs.CodeDefectAnalysis.m

do331.jobs.CheckCodeCompliance.m

do331.jobs.StaticModelAnalysis.m

do331.jobs.DesignErrorDetection.m

do331.jobs.ModelReview.m

mrails.jobs.CompileTests.m

do331.jobs.TestSimulation.m

do331.jobs.DeployUnprot

ectedDesign.m

do331.jobs.DeployProtectedDesign.m

do331.jobs.InspectCode.m

mrails.jobs.StoreMrailsVersion.m

rtwTargetInfo.m

fc_fcc_sample_time_s

fc_fcc_sample_time_d_s

FCC_coding_ref_coding

_reusable_da42_cfg_R16b_17_05_09.m

config_settings_reusable

FCC_coding_ref_coding_

singleton_da42_cfg_R16b_17_05_09.m

config_settings

FCC_coding_top

_coding_da42_cfg_R16b_17_05_09.m

top_level_config

fc_param_constant.h

fc_param_constant.c

madvisor_FCC_coding_R16b.mat

tAHRSVoter_001

tAHRSVoter_002

tAHRSVoter_003

fc_flightcontrol.sldd

fc_fcc

fc_actuatorLoop

fc_rolloff

fc_AHRSVoter

fc_innerLoop

fc_outerLoop

fc_fcc.slxp

fc_fcc.slx

mrails-info.txt

fsdlib

fc_limits.m

fc_scaling.m

fc_c_Phi_cmd_max

fc_c_Phi_cmd_min

fc_c_Phi_integr_max

fc_c_Phi_integr_min

fc_c_Theta_cmd_max

fc_

c_Theta_cmd_min

fc_c_Theta_integr_max

fc_c_Theta_integr_min

fc_c_act_cmd_max

fc_c_act_cmd_min

fc_c_act_integr_max

fc_c_act_integr_min

fc_c_r_cmd_max

fc_c_r_cmd_min

fc_c_r_integr_max

fc_c_r_integr_min

fc_c_scaling_Phi_in

fc_c_scaling_Theta_in

fc_c_scaling_act_pos_in

fc_c_scaling_act_pos_out

fc_c_scaling_r_in

fc_actuatorLoop.slx

fc_rolloff.slx

fc_actuatorLoop

fc_rolloff

fc_AHRSVoter.slx

fc_innerLoop.slx

fc_outerLoop.slx

c_AHRSVoter

fc_innerLoop

fc_outerLoop

fc_fcc.slx

fc_fcc

fc_p_M_K_init.m

fc_p_T_rolloff_s_init.m

fc_p_k_Phi1_init.m

fc_p_k_Phi2_init.m

fc_p_k_Theta1_init.m

fc_p_k_Theta2_init.m

fc_p_k_act_cmd_init.m

fc_p_k_d_act_init.m

fc_p_k_i_act_init.m

fc_p_k_p_act_init.m

fc_p_k_r1_init.m

fc_p_k_r2_init.m

fc_p_k_s_rolloff_init.m

fc_p_z5x1_init.m

fc_p_M_K

fc_p_T_rolloff_s

fc_p_k_Phi1

fc_p_k_Phi2

fc_p_k_Theta1

fc_p_k_Theta2

fc_p_k_act_cmd

fc_p_k_d_act

fc_p_k_i_act

fc_p_k_p_act

fc_p_k_r1

fc_p_k_r2

fc_p_k_s_rolloff

fc_p_z5x1

AHRS_voter_test.mldatx

t001_Mid_Value_Voting

t002_Average_Value_Voting

t003_Single_Value_Voting

workspace/reqs/fc_fcc.req

workspace/reqs/fc_actuatorLoop.req

workspace/reqs/fc_rolloff.req

workspace/reqs/fc_AHRSVoter.req

workspace/reqs/fc_innerLoop.req

workspace/reqs/fc_outerLoop.req

stanag4586-251

stanag4586-252

stanag4586-253

stanag4586-260

stanag4586-254

stanag4586-259

stanag4586-261

stanag4586-262

stanag4586-263

stanag4586-255

stanag4586-256

stanag4586-257

stanag4586-258

fc_flightcontrol.zip

fc_fcc.zip

fc_actuatorLoop.zip

fc_rolloff.zip

fc_AHRSVoter.zip

fc_innerLoop.zip

fc_outerLoop.zip

CMakeLists.txt

fc_fcc.c

fc_fcc.h

fc_fcc_private.h

fc_fcc_types.h

fc_actuatorLoop.c

fc_actuatorLoop.h

fc_actuatorLoop_private.h

fc_actuatorLoop_types.h

fc_rolloff.c

fc_rolloff.h

fc_rolloff_private.h

fc_rolloff_types.h

fc_AHRSVoter.c

fc_AHRSVoter.h

fc_AHRSVoter_private.h

fc_AHRSVoter_types.h

fc_innerLoop.c

fc_innerLoop.h

fc_innerLoop_private.h

fc_innerLoop_types.h

fc_outerLoop.c

fc_outerLoop.h

fc_outerLoop_private.h

fc_outerLoop_types.h

fc_actuatorLoop_mr_codeInfo.mat

fc_rolloff_mr_codeInfo.mat

fc_AHRSVoter_m

r_codeInfo.mat

fc_innerLoop_mr_codeInfo.mat

fc_outerLoop_mr_codeInfo.mat

fc_fcc_code_defect_data.txt

fc_fcc_code_defect_report.pdf

fc_fcc_code_compliance_data.txt

fc_actuatorLoop_code_compliance_data.txt

fc_rolloff_code_compliance_data.txt

fc_AHRSVoter_code_compliance_data.txt

fc_innerLoop_code_compliance_data.txt

fc_outerLoop_code_compliance_data.txt

fc_fcc_code_compliance_report.pdf

fc_actuatorLoop_code_com

pliance_report.pdf

fc_rolloff_code_compliance_report.pdf

fc_AHRSVoter_code_compliance_report.pdf

fc_innerLoop_code_compliance_report.pdf

fc_outerLoop_code_compliance_report.pdf

fc_fcc_mdladv_data.mat

fc_actuatorLoop_mdladv_data.mat

fc_rolloff_mdladv_data.mat

fc_AHRSVoter_mdladv_data.mat

fc_innerLoop_mdladv_data.mat

fc_outerLoop_mdladv_data.mat

fc_fcc_mdladv_report.html

fc_actuatorLoop_mdladv_report.html

fc_rol

loff_mdladv_report.html

fc_AHRSVoter_mdladv_report.html

fc_innerLoop_mdladv_report.html

fc_outerLoop_mdladv_report.html

fc_fcc_sldv_ded_data.mat

fc_actuatorLoop_sldv_ded_data.mat

fc_rolloff_sldv_ded_data.mat

fc_AHRSVoter_sldv_ded_data.mat

fc_innerLoop_sldv_ded_data.mat

fc_outerLoop_sldv_ded_data.mat

fc_fcc_sldv_ded_report.html

fc_actuatorLoop_sldv_ded_report.html

fc_rolloff_sldv_ded_report.html

fc_AHRSVoter_sl

dv_ded_report.html

fc_innerLoop_sldv_ded_report.html

fc_outerLoop_sldv_ded_report.html

t001_Mid_Value_Voting_cvdata.cvt

t002_Average_Value_Voting_cvdata.cvt

t003_Single_Value_Voting_cvdata.cvt

t001_Mid_Value_Voting_report.pdf

t002_Average_Value_Voting_report.pdf

t003_Single_Value_Voting_report.pdf

fc_fcc_slci_data.mat

fc_actuatorLoop_slci_data.mat

fc_rolloff_slci_data.mat

fc_AHRSVoter_slci_data.mat

fc_innerLoo

p_slci_data.mat

fc_outerLoop_slci_data.mat

fc_fcc_slci_report.html

fc_actuatorLoop_slci_report.html

fc_rolloff_slci_report.html

fc_AHRSVoter_slci_report.html

fc_innerLoop_slci_report.html

fc_outerLoop_slci_report.html

(Direct) Uptrace Artifacts

(Direct) Downtrace Artifacts

Selected Artifact

0 - Mrails Job Class

1 - undefined

2 - Model Element Library

3 - Init File (constant)

4 - constant

5 - Init File (model-reusable)

6 - model-reusable

7 - Init File (model-singleton)

8 - model-singleton

9 - Init File (model-top)

10 - model-top

11 - Init File (param-constant)

12 - param-constant

13 - Init File (test-sw-sw)

14 - test-sw-sw

15 - Requirement Link File

16 - SW High-Level Requirement

17 - Code Package

18 -

CMake Script File

19 - C Source Code

20 - Code Info

21 - Code Defect Data

22 - Code Defect Report

23 - Code Compliance Data

24 - Code Compliance Report

25 - Static Model Analysis MAT Data

26 - Static Model Analysis Report

27 - Design Error Detection MAT Data

28 - Design Error Detection Report

29 - Model Coverage Data

30 - Simulation Case Report

31 - Code Inspection MAT Data

32 - Code Inspection Report

Status Information Execution Trace

Project: fligh tcontrol

> PROJECT INFO

Dependencies

Artifact Tree

Traceability

> CLEANUP

CleanCache

CleanCodeCache

> ENVCHECK

CheckSLECI

CheckBugFixes

VerifyMrailsVersions

> ENVSETUP

RegisterTargetInfo

SetFCCSampleTime

LoadSLCodingConfiguration

UpdateSLFileGenControl

SetupBlockLibrary

SetupModelAdvisor

SetupRMI

UpdateSharedCodeDir

> DESIGN-VERIFICATION

Compile

StaticModelAnalysis

DesignErrorDetection

ModelReview

> SIMULATIO

N-TESTING

CompileTests

TestSimulation

> DESIGN-DEPLOY

DeployUnprotectedDesign

DeployProtectedDesign

> CODE

UpdateSharedCodeDir

GenerateSharedCode

GenerateCode

StoreMrailsVersion

> CODE-VERIFICATION

InspectCode

CheckCodeCompliance

CodeDefectAnalysis

ArtifactTree

Figure 11: Full artefact traceability graph.

well as the review and justiﬁcation capabilities are

further features not supported by these tools. As a

consequence, it has been a dedicated design decision

to implement a separate build tool in MATLAB.

Beyond build tools, the web platform Models Re-

ﬁnery (Modelery) (Couto et al., 2014) promotes a col-

laborative, web-based repository for sharing, versio-

ning, and organizing artefacts of a MBD process. It

does not analyse generated traceability, dependencies

or evaluate up-to-dateness artefacts.

With Simulink Projects, various process-related

features have found their way directly into MATLAB

and Simulink, amongst others a closer link to ver-

sion control systems, ﬁle dependency analyses, or

template features (Mahapatra et al., 2012). However,

these features are mostly standalone, isolated from a

workﬂow, and only provide a subset of the functio-

nality used in the demonstrated tool. Of course, any

build structure can be implemented by investing time

and money, but an infrastructure as provided by the

presented tool is not available out of the box.

7 LIMITATIONS AND FUTURE

WORK

Different assumptions have been necessary to imple-

ment the tool in the scope of the research project. Es-

pecially the functionality of Simulink and Stateﬂow

has to be limited to a reasonable subset due to its

feature-richness. Chosen are the features supported

by Simulink Code Inspector (cf. (The MathWorks

Inc., 2016b)). Furthermore, the presented build tool

bases on some design decisions. For example, it assu-

mes the usage of data dictionaries instead of the base

or model workspace.

Particularly in the context of safety-critical appli-

cations, tool qualiﬁcation, e.g., as described in DO-

330 (RTCA, 2011b), is an important corner-stone for

safety. If a tool eliminates, automates, or reduces a

required process, and the output itself is not veriﬁed

by a qualiﬁed tool or manual inspection, the user has

to perform a tool qualiﬁcation (Rierson, 2013). In

production, also the presented tool would require tool

qualiﬁcation in most cases. Since the tool is a research

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

200

project, tool qualiﬁcation has not been focused up to

now, but a tool qualiﬁcation kit may be developed on

top later on.

Next step is the application of the tool on a large

multi-module project to evaluate its scalability. Also

other process workﬂows beyond DO-178C should be

integrated in subsequent projects to prove general ap-

plicability. Future research may also focus on a stron-

ger interaction with MATLAB, Simulink, and State-

ﬂow. Instead of manually triggering a rescan of the

project, callbacks might be used to automatically up-

date the status of jobs in the background in situ, whe-

never a model or object has been changed.

8 CONCLUSIONS

The paper has introduced a build tool for MBD, which

seamlessly integrates process-oriented features, like

model scaffolding based on CoC, to improve standard

compliance and standardisation from the beginning.

Additionally, a unique interface for automatic, semi-

automatic, and manual tasks, including review and

justiﬁcation capabilities, as well as traceability cap-

turing in the background has been presented.

A short example has demonstrated the necessity

for build automation on the one hand, and the high

process coverage, which is achievable by integrating

various tools into the build and parsing the individual

results, on the other hand. The discussion of related

work has highlighted the difference to existing soluti-

ons. Finally, a summary of limitations coming along

with the build tool and future enhancement plans has

been provided.

The presented tool has the ability to solve pro-

blems of different process participants. With the Life

Cycle Package, the Process Manager is able to dis-

tribute workﬂows, standards, checklists, and proce-

dures in a new level of detail. Model scaffolding

improves the structure and clarity of software mo-

dules. Developers must read less documents and a

much higher standard compliance is already expected

by construction. Additionally, less time is invested

in reviews, since checklists must only be re-reviewed

if the tool detects deprecation (in contrast to written

checklists). Traceability does not have to be created

retrospectively or manually, but is implicitly captured

during build. This eliminates deprecated traceability

links. Various methods to evaluate completeness of

artefacts, compliance to standards, consistency, and

cleanliness support assessors in their daily work or

are pluggable to other build automation systems, like

a CI server.

With the presented tool, higher process compli-

ance is achieved whilst investing less effort. It aligns

with the trends of modern software development and

has the potential to support increasing software com-

plexity and size, but also to accelerate development

cycles in high-integrity MBD.

REFERENCES

Asuncion, H. U., Asuncion, A. U., and Taylor, R. N. (2010).

Software traceability with topic modeling. In Kra-

mer, J., Bishop, J., Devanbu, P., and Uchitel, S., edi-

tors, Proc. of the 32nd ACM/IEEE International Con-

ference on Software Engineering - ICSE ’10, page 95,

New York, New York, USA. ACM Press.

Basagiannis, S. (2016). Software certiﬁcation of airborne

cyber-physical systems under DO-178C. In Proc. of

2016 International Workshop on Symbolic and Nume-

rical Methods for Reachability Analysis (SNR), pages

1–6. IEEE.

Berglund, T. and McCullough, M. (2011). Building and

testing with Gradle. O’Reilly, Beijing and Sebastopol.

Bhatt, D., Madl, G., Oglesby, D., and Schloegel, K. (2010).

Towards Scalable Veriﬁcation of Commercial Avio-

nics Software. In AIAA, editor, Proc. of AIAA Info-

tech@Aerospace 2010.

Broy, M., Kirstan, S., Krcmar, H., and Sch

atz, B. (2014).

What is the Beneﬁt of a Model-Based Design of Em-

bedded Software Systems in the Car Industry? In Ma-

nagement Association, I. R., editor, Software Design

and Development, pages 310–334. IGI Global.

Conrad, M., Englehart, M., Erkkinen, T., Lin, X., Nirakh,

A. R., Potter, B., Shankar, J., Szpak, P., Yan, J., and

Clark, J. (2012). Automating Code Reviews with Si-

mulink Code Inspector. In Dagstuhl, editor, Proc. of

VIII Dagstuhl-Workshop, M

unchen. fortiss GmbH.

Conrad, M., Friedman, J., and Sandmann, G. (2009). Ve-

riﬁcation and Validation According to IEC 61508:

A Workﬂow to Facilitate the Development of High-

Integrity Applications. SAE International Journal of

Commercial Vehicles, 2(2):272–279.

Couto, R., Ribeiro, A. N., and Campos, J. C. (2014). The

Modelery: A Collaborative Web Based Repository.

In Hutchison, D., Kanade, T., Kittler, J., Kleinberg,

J. M., Kobsa, A., Mattern, F., Mitchell, J. C., Naor,

M., Nierstrasz, O., Pandu Rangan, C., Steffen, B., Ter-

zopoulos, D., Tygar, D., Weikum, G., Murgante, B.,

Misra, S., Rocha, A. M. A. C., Torre, C., Rocha, J. G.,

Falc

ao, M. I., Taniar, D., Apduhan, B. O., and Gervasi,

O., editors, Computational Science and Its Applicati-

ons – ICCSA 2014, volume 8584 of Lecture notes in

computer science, pages 1–16. Springer International

Publishing, Cham.

Dillaber, E., Kendrick, L., Jin, W., and Reddy, V., editors

(2010). Pragmatic Strategies for Adopting Model-

Based Design for Embedded Applications. SAE In-

ternational.

A Process-oriented Build Tool for Safety-critical Model-based Software Development

201

Erkinnen, T. and Potter, B. (2009). Model-Based Design

for DO-178B with Qualiﬁed Tools: AIAA Modeling

and Simulation Technologies Conference and Exhibit.

American Institute of Aeronautics and Astronautics

Inc, Hyatt Regency McCormick Place, Chicago Illi-

nois.

Estrada, R. G., Sasaki, G., and Dillaber, E. (2013).

Best practices for developing DO-178 compliant

software using Model-Based Design. AIAA Info-

tech@Aerospace, Boston, MA.

Gallina, B. (2014). A Model-Driven Safety Certiﬁcation

Method for Process Compliance. In Proc. of 2014

IEEE International Symposium on Software Reliabi-

lity Engineering Workshops, pages 204–209. IEEE.

Gotel, O., Cleland-Huang, J., Hayes Huffman, J., Zisman,

A., Egyed, A., Gr

unbacher, P., Dekhtyar, A., Anto-

niol, G., Maletic, J., and M

ader, P. (2012). Traceabi-

lity Fundamentals. In Cleland-Huang, J., Gotel, O.,

and Zisman, A., editors, Software and Systems Trace-

ability, pages 3–22. Springer London, London.

Hochstrasser, M., Hornauer, M., and Holzapfel, F. (05 Oct.

2016). Formal Veriﬁcation of Flight Control Applica-

tions along a Model-Based Development Process: A

Case Study.

Hochstrasser, M., Schatz, S. P., N

urnberger, K., Hornauer,

M., Myschik, S., and Holzapfel, F., editors (2017). As-

pects of a Consistent Modeling Environment for DO-

331 Design Model Development of Flight Control Al-

gorithms.

Holten, D. (2006). Hierarchical Edge Bundles: Visuali-

zation of Adjacency Relations in Hierarchical Data.

IEEE Transactions on Visualization and Computer

Graphics, Volume 12:p. 741–748.

Hornauer, M. and Holzapfel, F. (2011). Model Based Tes-

ting for CS-23 Avionic and UAV Applications: DGLR

Workshop 2011.

Hornauer, M., Schuck, F., and Holzapfel, F. (2013). Wech-

selwirkungen zwischen GNC Algorithmus und Soft-

ware.

Humble, J. and Farley, D. (2015). Continuous delivery: Re-

liable software releases through build, test, and de-

ployment automation. A Martin Fowler Signature

Book. Addison-Wesley, Upper Saddle River, NJ, tenth

printing edition.

Lochmann, H. and Hessellund, A. (2009). An integrated

view on modeling with multi domain-speciﬁc langua-

ges. In Proc. of the IASTED International Conference

Software Engineering.

ader, P., Jones, P. L., Zhang, Y., and Cleland-Huang, J.

(2013). Strategic Traceability for Safety-Critical Pro-

jects. IEEE Software, 30(3):58–66.

Mahapatra, S., Ghidella, J., and Walker, G. (2012). Team-

Based Collaboration in Model-Based Design. In AIAA

Modeling and Simulation Technologies Conference,

Reston, Virigina. American Institute of Aeronautics

and Astronautics.

Marques, J. C., Yelisetty, S. M. H., Dias, L. A. V., and

da Cunha, A. M. (2012). Using Model-Based De-

velopment as Software Low-Level Requirements to

Achieve Airborne Software Certiﬁcation. In Proc. of

2012 Ninth International Conference on Information

Technology - New Generations, pages 431–436. IEEE.

OMG Object Management Group (Apr. 2008). Software &

System Process Engineering Meta-Models Speciﬁca-

tion (SPEM 2.0).

Paz, A. and El Boussaidi, G. (2016). On the Exploration of

Model-Based Support for DO-178C-Compliant Avio-

nics Software Development and Certiﬁcation. In Proc.

of 2016 IEEE International Symposium on Software

Reliability Engineering Workshops (ISSREW), pages

229–236. IEEE.

Potter, B. (2012). Complying with DO-178C and DO-331

using Model-Based Design.

Rahman, A., Partho, A., Meder, D., and Williams, L.

(2017). Which Factors Inﬂuence Practitioners’ Usage

of Build Automation Tools? In Proc. of 2017

IEEE/ACM 3rd International Workshop on Rapid

Continuous Software Engineering (RCoSE), pages

20–26. IEEE.

Rierson, L. (2013). Developing safety-critical software: A

practical guide for aviation software and DO-178C

compliance. CRC Press LLC, Boca Raton, FL.

RTCA (2011a). DO-178C - Software Considerations in Ai-

rborne Systems and Equipment Certiﬁcation.

RTCA (2011b). DO-330 Software Tool Qualiﬁcation Con-

siderations.

RTCA (2011c). DO-331 - Model-Based Development and

Veriﬁcation Supplement to DO-178C and DO-278A.

Ruby, S. (2016). Agile Web Development with Rails 5. Prag-

matic Bookshelf.

Seibel, A., Hebig, R., and Giese, H. (2012). Traceability

in Model-Driven Engineering: Efﬁcient and Scalable

Traceability Maintenance. In Cleland-Huang, J., Go-

tel, O., and Zisman, A., editors, Software and Systems

Traceability, pages 215–240. Springer London, Lon-

don.

Seibel, A., Neumann, S., and Giese, H. (2010). Dynamic

hierarchical mega models: Comprehensive traceabi-

lity and its efﬁcient maintenance. Software & Systems

Modeling, 9(4):493–528.

Sonatype Company (Oct. 2008). Maven: The Deﬁnitive

Guide. O’Reilly, Cambridge.

The MathWorks Inc. (2016a). DO Qualiﬁcation R2016b:

Model-Based Design Workﬂow for DO-178C. Natick,

MA, USA.

The MathWorks Inc. (Sep. 2016b). Simulink Code Inspector

Reference: R2016b. Natick, MA, USA.

Zisman, A. (2012). Using Rules for Traceability Creation.

In Cleland-Huang, J., Gotel, O., and Zisman, A., edi-

tors, Software and Systems Traceability, pages 147–

170. Springer London, London.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

202