A Process-oriented Build Tool for Safety-critical Model-based Software
Development
Markus Hochstrasser
1
, Stephan Myschik
2
and Florian Holzapfel
1
1
Institute of Flight System Dynamics, TU M
¨
unchen, Boltzmannstraße 15, 85748 Garching, Germany
2
Chair of Flight Mechanics and Flight Control, Universit
¨
at der Bundeswehr M
¨
unchen,
Werner-Heisenberg-Weg 39, 85577 Neubiberg, Germany
Keywords:
Build Automation, Workflow 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 Stateflow. Beyond classical build automation functionality, it supports and acce-
lerates process workflows. The tool provides infrastructure to formalize and ship workflows, checklists, and
standards, but also features to assess completeness, consistency, compliance, and cleanliness with respect to
them. Additionally, it allows definition of dynamic, incrementally updated checklists, and composes tracea-
bility in parallel with the build. The efficacy 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-
fication techniques. Algorithms rapidly grow in size
and complexity (Basagiannis, 2016). At the same
time, software has to fulfill 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 fulfill objectives (Bhatt et al., 2010).
By developing flight 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 Stateflow
1
(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-
fine 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 difficult to communicate a pro-
1
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
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
191
cess setup to developers in a way, in which they can
efficiently apply it. In consequence, developers st-
ruggle with the tool complexity
2
. A process setup
for MATLAB, Simulink, and Stateflow may contain a
whole modeling environment with configuration 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 workflows 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
justification workflow. 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 verification 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, specifically 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 workflow 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-
2
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 finally given in Section 7, before
the results are summarized in Section 8.
The presented tool has originally been created to
support a MBD workflow fulfilling objectives of DO-
178C/DO-331 in accordance with the MathWorks re-
ference workflow (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 fit into workflows (Rahman et al., 2017).
Thus, an important aspect of the presented tool is to
accompany the whole workflow, but at the same time
allow developers using existing, familiar routines.
Figure 1 depicts a typical MBD change workflow
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 workflow.
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 configuration, modeling ru-
les, activities, and checklists to fulfill 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 modification of the design
(2). As soon as the model has been updated, code ge-
neration and verification tasks are executed to create
needed artefacts (4). In all cases, identification of im-
pacted files 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 fit to the
latest model version and checklists must be reevalu-
ated step by step. Justifications 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 workflow 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 finished, pre-defined build
jobs (e.g., code generation or analysis jobs on mo-
del and code) can be executed incrementally based on
modifications 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 benefit 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 fulfilled 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 fulfills approval requirements
(e.g., if all warnings are justified).
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 workflow 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 specification, 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
workflow. 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
verification process together. Typically, different soft-
ware modules are maintained by different developers.
Here, any module at least consists of a single Simu-
link Projects
3
instance and a XML module descrip-
tion. The XML description is the basic information
source of the module and defines a unique ID, a name
of the module, other module dependencies that shall
be loaded, and the Life Cycle Package that applies to
3
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 workflow 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 workflow 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 conflicts are detected and
reported. Depending on the Life Cycle Package con-
figuration, integrated dependencies may be initialized
differently than the current working module, for ex-
ample with regard to the set search path
4
.
4
The search path specifies a set of folders where MAT-
LAB looks for files, 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 workflow.
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 beneficial, 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 workflows 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 files, 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
5
. But fin-
ding the textual guidelines of interest for the various
configurations 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 workflow.
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 significant overhead by repeating tasks and secu-
rity issues due to bad configurations. 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 Configuration (CoC)”. The idea behind
the principle CoC is reducing a set of configurati-
ons to a smaller set of conventions. In most cases,
it is sufficient for developers to learn the conventions
without caring about the configuration behind. “The
Convention over Configuration pattern rewards deve-
lopers for adhering to naming conventions and enfor-
ces this in a stricter manner by building it into the
framework”
6
.
5
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]
6
Chen, Nicolas, 2006, http://softwareengineering.vazex
qi.com/files/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
configuration work with model scaffolding provided
to the user as command-line tool. To define conventi-
ons, the Process Manager customizes pre-defined 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 configured Simulink Projects as defined by
guidelines,
initialization of data from files (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 defines the
configuration for a special type of Simulink Bus,
which is imported from existing C header files 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 filename pattern
<module-id> <busname> Bus init.m and registers
helpful commands, like
create bus-imported <busname>
to create a fully configured parameter in the Simulink
workspace, together with an initialization script.
The scaffolding interface imposes restrictions on
the user, like storing files at a specific location or
using pre-defined 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 finishing 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 defined within the Life Cycle Package
XML specification 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-defined, 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-
fine 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 files and objects are of-
ten the result of modifications, renaming, or remai-
ning intermediate artefacts of the implementation. If
projects are not regularly cleaned up, unneeded files
accumulate and the question, whether a file 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 files
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 fi-
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 files 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 first 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 workflow 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 fix
on the host system has been detected during build. In
this case, it is classified as non-justifiable 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 classified as non-justifiable.
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 justification 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 Stateflow APIs, tailored and dynamic re-
view lists can be generated upon model information.
In Figure 5, a non-justifiable status information
has been introduced. Alternatively, Figure 7 shows
an exemplary interactive model review checklist, em-
bedded in the build workflow. In a first run, checklist
items are marked with the status WARN. By manu-
ally ticking items and/or adding a justification text,
the status can be mitigated to PASS or any other status
according to a specified 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 first, 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
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 definition,
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,
(M
¨
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 flexibility, a trace can be defi-
ned between any type of software artefact, from infor-
mal to formal (cf. (Seibel et al., 2012)), in-memory,
or on the file 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 modification.
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-
dified in situ with the build process.
The methods chosen to create traces are rule-
based techniques. They provide the most flexibility
and can cope with the heterogeneity of artefacts (Zis-
man, 2012). Furthermore, these methods support the
definition of candidate traces, which are traces that
finally must exist but are not created yet. Rules are
either defined when setting up the model scaffolding
interface or with the specification of the job. In the lat-
ter case, the rules describe traceability creation, but at
the same time define inputs and outputs for the build.
This double function is one of the core principles,
since it reduces configuration effort. Traceability and
the build process benefit 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
file dependency analysis. However, also every non-
MATLAB based algorithm can be included.
4.2 Data Model
To efficiently 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 (simplified).
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 identified. For example,
Meta-Artefacts may be created for different kinds of
files, 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 efficient 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 efficient.
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 Stateflow 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 Workflow for DO-178C (The MathWorks Inc.,
2016a). The data bases on the DO-178C case study
performed by Bill Potter for an helicopter autopilot
7
.
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 verifies that required bug fixes 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
7
https://nl.mathworks.com/matlabcentral/fileexchange/
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 verified 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
superficially described by the TIM in Figure 10.
Table 1: Example build workflow. 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 Workflow R E RC
Design Verification
(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 Verification
(11) Auto C. Review (10) x x
(12) Code Compliance Checks (10) x x
(13) Code Defect Analysis (10) x x
The final workflow 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 simplified workflow, 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 Stateflow in the depth as the
Figure 10: Example Traceability Information Model (sim-
plified).
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
8
or
Yakindu Traceability
9
provide powerful traceability
features, but are not integrated with build automation
and mainly focus on retrospective traceability cap-
ture.
Build tools like Apache Ant
10
, Apache Maven
11
,
or Gradle
12
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 verification
tools is necessary in the presented use case. The inte-
raction with a multi-functional traceability graph as
8
Traceability management tool of Dassault Systems,
https://www.3ds.com/products-services/catia/products/req
tify/ [Accessed on 2017/03/08]
9
Traceability management solution of itemis AG,
https://www.itemis.com/en/yakindu/traceability/ [Accessed
on 2017/03/08]
10
Apache Ant is a Java library to setup build processes,
http://ant.apache.org [Accessed on 2017/27/07]
11
Apache Maven is a project management and com-
prehension tool, https://maven.apache.org, [Accessed on
2017/07/27]
12
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
0
-
M
r
a
i
l
s
J
o
b
C
l
a
s
s
1
-
u
n
d
e
f
i
n
e
d
2
3
4
-
c
o
n
s
t
a
n
t
5
6
7
8
9
1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
-
C
S
o
u
r
c
e
C
o
d
e
2
0
2
1
2
2
2
3
2
4
2
5
2
6
2
7
2
8
2
9
3
0
3
1
3
2
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
f
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
CMakeLists.txt
CMakeLists.txt
CMakeLists.txt
CMakeLists.txt
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 justification 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-
finery (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, file dependency analyses, or
template features (Mahapatra et al., 2012). However,
these features are mostly standalone, isolated from a
workflow, 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 Stateflow
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 qualification, 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 verified
by a qualified tool or manual inspection, the user has
to perform a tool qualification (Rierson, 2013). In
production, also the presented tool would require tool
qualification in most cases. Since the tool is a research
MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development
200
project, tool qualification has not been focused up to
now, but a tool qualification 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 workflows 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-
flow. 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
justification 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 workflows, 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 certification 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 Verification 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 Benefit 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-
rification and Validation According to IEC 61508:
A Workflow 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 Qualified 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 Certification
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 Verification 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-specific langua-
ges. In Proc. of the IASTED International Conference
Software Engineering.
M
¨
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 Certification. 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 Specifica-
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 Certification. 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 Influence 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 Certification.
RTCA (2011b). DO-330 Software Tool Qualification Con-
siderations.
RTCA (2011c). DO-331 - Model-Based Development and
Verification 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: Efficient 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 efficient maintenance. Software & Systems
Modeling, 9(4):493–528.
Sonatype Company (Oct. 2008). Maven: The Definitive
Guide. O’Reilly, Cambridge.
The MathWorks Inc. (2016a). DO Qualification R2016b:
Model-Based Design Workflow 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