A Cloud-based Collaboration Platform for Model-based Design of

Cyber-Physical Systems

Peter Gorm Larsen

1 a

, Hugo Daniel Macedo

1 b

, John Fitzgerald

2 c

, Holger Pfeifer

Martin Benedikt

, Stefano Tonetta

5 d

, Angelo Marguglio

, Sergio Gusmeroli

and George Suciu Jr.

DIGIT, Department of Engineering, Aarhus University, Aarhus, Denmark

School of Computing, Newcastle University, U.K.

fortiss, Germany

Virtual Vehicle, Austria

Fondazione Bruno Kessler, Italy

Engineering Ingegneria Informatica S.p.A., Italy

Politecnico di Milano, Italy

BEIA Consult, Romania

Keywords:

Model-based Design, Tools, Models, Collaboration Platform.

Abstract:

Businesses, particularly small and medium-sized enterprises, aiming to start up in Model-Based Design

(MBD) face difﬁcult choices from a wide range of methods, notations and tools before making the signif-

icant investments in planning, procurement and training necessary to deploy new approaches successfully.

In the development of Cyber-Physical Systems this is exacerbated by the diversity of formalisms covering

computation, physical and human processes. In this paper, we propose the use of a cloud-enabled and open

collaboration platform that allows businesses to offer models, tools and other assets, and permits others to

access these on a pay-per-use basis as a means of lowering barriers to the adoption of MBD technology, and

to promote experimentation in a sandbox environment.

1 INTRODUCTION

The digital transformation that industry and society is

experiencing creates many opportunities for increas-

ing the delegation of tasks to machines. The depend-

ability of the resulting systems therefore becomes

critical not only for compliance with regulations and

certiﬁcation standards, but also for societal accep-

tance of the transformation. Modern innovative prod-

ucts and systems combine physical and networked

computational processes. Such Cyber-Physical Sys-

tems (CPSs) place new multi-disciplinary demands

on traditional engineering processes because of the

heterogeneity and complexity of the constituent ele-

ments, and of their interaction with the environment.

https://orcid.org/0000-0002-4589-1500

https://orcid.org/0000-0002-8882-4500

https://orcid.org/0000-0001-7041-1807

https://orcid.org/0000-0001-9091-7899

Model-Based Design (MBD) has demonstrated

the potential to increase the quality of CPSs (Van der

Auweraer et al., 2013). MBD prescribes the use of

system models through the development process in

order to represent system structure and behaviours,

providing a basis for machine-assisted analysis of

system properties, and informing design decisions

through processes of reﬁnement into implementation.

A considerable body of research has provided

model-based solutions to the challenges of CPS de-

sign (Beckers et al., 2007; Sztipanovits et al., 2015),

but businesses that could beneﬁt from such ap-

proaches may face barriers to their adoption. It is

possible that as a consequence, MBD methods and

tools appear largely to be applied in domains such

as aerospace where the return of investment can take

decades. By contrast, Small and Medium-sized En-

terprises (SMEs) require considerable ﬂexibility to

change processes to adopt MBD, and may lack in-

house expertise. In addition, the selection, procure-

Larsen, P., Macedo, H., Fitzgerald, J., Pfeifer, H., Benedikt, M., Tonetta, S., Marguglio, A., Gusmeroli, S. and Suciu Jr., G.

A Cloud-based Collaboration Platform for Model-based Design of Cyber-Physical Systems.

DOI: 10.5220/0009892802630270

In Proceedings of the 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2020), pages 263-270

ISBN: 978-989-758-444-2

263

ment, training and deployment costs for some meth-

ods and tools can be discouragingly high. In general,

it is difﬁcult for SMEs to invest in acquiring the nec-

essary background for example because of the high

license fees from commercial vendors of MBD assets.

In this position paper, we report on an approach

that aims to make MBD more accessible to a range

of businesses, but especially SMEs, involved in the

development of cyber-physical products and systems.

This centres on the servitisation of modelling, sim-

ulation and analysis tools for CPS design, offered

through an open collaboration platform. The new

HUBCAP project

aims to implement and evaluate

this approach, alongside provision of other services

for SMEs through a network of innovation hubs. In

this paper we focus on the platform.

The goal of our HUBCAP project is to provide a

collaboration platform that enables users to access ad-

vanced CPS design and engineering solutions, includ-

ing models and tools such as those offered, for exam-

ple, by the Modelica association community (Fritz-

son, 2015) or the INTO-CPS association commu-

nity (Larsen et al., 2016).This will be done through

sandboxes – environments in which users can test and

experiment with a solution in a secure and trusted en-

vironment before investing in longer-term or larger-

scale adoption. The platform will also facilitate col-

laboration services that enable the sharing of knowl-

edge among providers of MBD solutions, so that new

models, tools and techniques and related services may

be extended by combining existing assets.

This paper provides an overview of our proposed

collaboration platform in Section 2, and more detail

on the sandbox functionality in Section 3. Section 4

indicates how assets such as models can be accessed

from a catalogue inside the collaboration platform.

Afterwards Section 5 explains how we envisage the

collaboration platform to be populated with MDB as-

sets by means of open calls targeted at SMEs, en-

abling them to get ﬁnancial support. Finally, we con-

clude in Section 6 by discussing the work required to

realise and evaluate such a platform.

2 THE COLLABORATION

PLATFORM

The HUBCAP Collaboration Platform is based on

the DIHIWARE open source solution developed by

the MIDIH H2020 EU project

and currently in use

in many ecosystems in Europe (Kainz et al., 2019).

See http://www.hubcap.eu.

See http://midih.eu/.

DIHIWARE offers a complete collaboration environ-

ment inspired by Enterprise Social Software (Cook,

2008). It supports both “Access to” and “Collaborate

with” services, providing companies access to the lat-

est knowledge, expertise and technology during their

digital transformation paths toward piloting, testing

and experimenting with new digital technologies.

The knowledge-driven services, complemented by

the collaborative and innovation side of the platform,

are intended to create a virtual environment where

providers and consumers of digital technologies are

not just matching assets and needs, but they are col-

laborating together towards joint innovations. This

environment will be the foundation on which spe-

ciﬁc customisations (environment customisation, cat-

alogue designing, and dedicated user journey) will be

realised to meet the speciﬁc needs of HUBCAP.

The platform integrates open source technologies

(e.g., those coming from the FIWARE Community

with enterprise-grade solutions such as Liferay Por-

tal). DIHIWARE has four main subsystems (Fig-

ure 1a):

Identity Manager: This subsystem centralises user

authentication, deﬁning roles and granting access

while using the other applications.

Marketplace: This subsystem handles the creation

of company offerings by means of a product cat-

alogue in which MBD assets and services will be

shared. End users can view and interact with as-

sets through this subsystem, while suppliers use it

to manage their asset and service catalogue.

Knowledge Base: This subsystem supports seman-

tic indexing and retrieval functions, grounded

on semantic technologies and providing a set of

services for creating awareness, dissemination,

training, and managing connections among user-

generated content.

Social Portal: This subsystem offers tools for social

activity, user collaboration, matchmaking, and ex-

pert search, one of the key offerings on DIHI-

WARE.

HUBCAP extends this foundation framework with

the sandbox capability. The overall idea is that it

should form the centre of an ecosystem in which dif-

ferent organisations can undertake model-based col-

laborations. In order to protect intellectual property

of the suppliers of assets, the platform needs to enable

white-box, grey-box and black-box models so that it

is possible to control access. This can for example

be accomplished using the Functional Mockup Inter-

face (FMI) standard that is supported by range of cur-

rent tools (Blochwitz, 2014) to enable co-simulation

See http://ﬁware.org/.

SIMULTECH 2020 - 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

264

(a) DIHIWARE Platform (b) The HUBCAP Platform

Figure 1: Growing from the DIHIWARE to the HUBCAP Platform.

of a collection of different individual models (Gomes

et al., 2018).

The platform’s collaboration functions will enable

diverse partners to work together through the sharing

of controlled access to models. We imagine that an

Original Equipment Manufacturer (OEM) may invite

their suppliers to join the model-based development

of a CPS. Many of the suppliers will wish to provide

the models as black boxes. For the OEM this is not

a problem as long these diverse models can be inte-

grated in their analysis of CPS-level properties. The

idea is that all the partners will be able collectively to

analyse the composition from the sandbox.

3 THE SANDBOX

FUNCTIONALITY

In a typical MBD setup there are three classes of as-

sets:

• models, which are mathematical or formal ab-

stractions of system elements (components or

subsystems);

• tools, which are software packages and their de-

pendencies that enable the development, analysis,

and simulation of models; and

• Operating Systems (OSs), which refers to a soft-

ware environment providing libraries and depen-

dencies needed to run the tools.

Adding a sandbox feature to the DIHIWARE collabo-

ration platform requires the support of a multitude of

tools, dependencies, OSs. This calls for a virtualisa-

tion approach in which the tools involved in a given

experiment are deployed for each individual user in

an environment that is populated with all the depen-

dencies required. In addition to plain virtualisation, a

sandbox mechanism provides improved security and

minimises perceived interference among users. We

envisage three kinds of sandboxes, each with a spe-

ciﬁc complexity and level of service:

Demo Sandbox: A simple web application demon-

stration, where inputs may be predeﬁned for user

experimentation. This supports simple cases in

which a simple web site or application is suf-

ﬁcient to provide users with the inner workings

of an experiment, serving as a potentially ad-

vanced/animated repository of the models and

shared artefacts, with pointers on to the vendor

sites. This serves as a solution for tool ven-

dors/experiments with a need to host results with-

out the need for signiﬁcant dependence on the un-

derlying OS features.

Container Sandbox: A web application deployed

using a standard virtualised processes approach in

which different containers host different services

of the application and are connected through a vir-

tual network interface. This option allows exper-

iments involving tools requiring a single OS, but

needing complex software environments (differ-

ent versions of an environment) or a multiple ser-

vices running in different containers.

Cloud Sandbox: A single sandbox is implemented

by a set of virtual machines (VMs) operating on

top of a Kernel-based Virtual Machine (KVM),

connected through a KVM virtual network. The

VMs inside a sandbox can access a common NFS

storage to retrieve some input data (e.g., existing

models) and to exchange data among themselves

(e.g., generated models). This alternative sup-

ports experiments which are based on tools requir-

ing different OSs or OS versions are allowed to

run, exchange data via the network, and exchange

ﬁles.

It is possible to realise a Demo or Container Sand-

box using the Cloud type. A working prototype of

this approach has been constructed, and details of it

follow. The prototype allows a pre-registered HUB-

A Cloud-based Collaboration Platform for Model-based Design of Cyber-Physical Systems

265

Figure 2: The HUBCAP Sandbox architecture.

CAP Platform user to select a combination of models,

tools, and OS, pack them in an isolated sandbox and

start playing with them via a web browser. Examples

of use cases for the different kinds of sandboxes are

given in Section 4.2.

3.1 Architecture

A sandbox is implemented as an isolated set of VMs

(each one running a CPS tool) that interact with each

other sharing a virtual dedicated subnet and a ded-

icated NFS storage service. No interaction is per-

mitted between the VMs belonging to different sand-

boxes. The sandbox capability integrated with the DI-

HIWARE Platform is therefore a sort of private cloud

service provider plus the middleware to manage and

mediate the access to those cloud services. In addi-

tion, as many cloud service providers offer the ca-

pability to select a combination of hardware and op-

erating systems, the HUBCAP Platform offers you

to select a combination of OS environments, tools,

and models to run an experiment using the HUBCAP

sandbox feature.

The sandbox service is outlined in Figure 2. The

DIHIWARE Platform is enhanced with a broker com-

ponent (labelled as Sandboxes Broker in the ﬁgure),

which hosts a web application mediating the access

of different users (Client 1 and Client 2) to the sand-

boxes they requested (Sandbox 1 and Sandbox 2 re-

spectively). All the users will use an Internet browser

to access the tools in the sandbox and all the interac-

tions are mediated by the broker.

The Sandbox Broker has access to the catalogues

of different models, tools, and pre-conﬁgured OSs

that are available, so an end user can simply pick a

valid combination to request a sandbox. In addition

to those catalogues, the Sandbox Broker keeps user

information, such as the user’s models (private copies

of the model in the catalogue, which may have been

modiﬁed by the user while using the sandbox) and

the sandboxes the user created. This information is

important to allow the creation of new sandboxes.

The operation of user requests and the sandboxing

logic is provided by the Sandboxing Kernel, which is

a component that interacts with the system Hypervi-

sor to launch the different constituents of a sandbox,

namely:

• NFS - Network File System providing storage in

the form of shared folders where model ﬁles and

tool outputs are placed.

• VLANS - Virtual networks restricting the commu-

nications of the VMs inside a sandbox to the set

of VMs composing it and those only.

• V.OS - Virtual machines running the OSs support-

ing a tool, a remote desktop protocol to provide

the clients access to the tool display, and other

monitor and interoperability tools to operate the

VM inside the Kernel.

• Tools - The tools running a model or a multi-

model.

• Models - A mathematical/formal description of a

component.

The operation relies on a database of metadata about

the different sandboxes (the Sandboxes Metadata

component in the ﬁgure). This component stores and

keeps track of the sandboxes’ states (running, sus-

pended, . . . ) and user ownership of the resources. It is

worth highlighting that the Kernel has direct network

connections to the Sandboxes’ VLANs.

SIMULTECH 2020 - 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

266

3.2 Security

To ensure the data privacy of models and analysis re-

sults produced in the HUBCAP experiments, we en-

visage a security middleware to enhance the HUB-

CAP Platform with the due security and protection

mechanisms. The sandbox design itself should ease

security auditing and assurance. For instance, our

current proposal follows a trusted “kernel architec-

ture” where the sandboxes manager/broker launches

sandboxes and mediates its interactions. An exam-

ple of such is the multi-process architecture design of

Google Chrome, where each tab containing untrusted

code (not necessarily malicious, but not possible to be

assumed secure) runs in a sandbox environment and

accesses the system resources through a trusted bro-

ker ensuring independence of the different tabs. Thus

it is possible to secure the platform by a general veri-

ﬁcation approach (Jomaa et al., 2018).

Moreover, the components of the sandbox kernel

are open source, e.g. Hypervisor, NFS server, and the

security will be based on Data-Service Sovereignty

principles, in order to enhance trust among beneﬁ-

ciaries of the HUBCAP Platform (exchanging data

and services), but also intended to provide protec-

tion mechanisms to prevent the inﬁltration of malware

into the collaboration platform by applying known

malware detection techniques, for instance (Macedo

and Touili, 2013), which will systematically check

the collaboration platform FMUs for malicious be-

haviour. Furthermore, secure isolation (Suciu et al.,

2018) and security information and event manage-

ment can ensure that aggregated data and log records

can be automatically analysed giving a clear picture

of what is happening on the platform.

3.3 Limitations

In the HUBCAP cloud environment, a single CPS tool

is installed on a V.OS. Such a customised V.OS is then

frozen and referenced in a tools catalogue, ready to

be executed by the sandbox hypervisor by different

HUBCAP users who are able pick up the same tool

from the tools catalogue, run it on different sandboxes

at the same time, and even customise it with other

services and add them to the catalogue. This poses a

problem when tool dependencies are not open-source

software (OSS) or not resource efﬁcient.

If an experiment demands a proprietary OS, which

in turn demands a license per user, or blocks the pos-

sibility of using the OS in a virtualised hardware envi-

ronment, the sandbox facility may be of limited value.

We expect to explore and clarify these issues as tools

are checked into the ecosystem and the analysis of

corner cases starts to provide results. Nevertheless,

several issues need to be addressed before the sand-

boxing concept becomes a public service:

1. How to license sandboxes containing non-OSS

or incompatible OSS licenses packages. The

main question is whether the suppliers of such

license-based software in the longer term will see

an advantage also making versions of their soft-

ware available in a pay-as-you-go servitisation ap-

proach.

2. How to deal with resource inefﬁcient sandboxes.

If the tool and model combination makes heavy

use of resources (CPU, RAM, Storage) it may

be difﬁcult to obtain acceptable levels of perfor-

mance in cases where this sandbox is made avail-

able for multiple users. A pay-as-you go solution

approaches the issue using basic economics, but

our research resources are limited and better use

may be made of them in serving experiments that

are ‘greener’ and allow more users to participate.

4 CATALOGUES OF MODELS

AND MBD SERVICES

The HUBCAP Platform will provide access to assets

including models and tools for MBD. The analysis ca-

pabilities of the tools will be available as services to

be tested in a sandbox. The MBD services will in-

clude support for modelling of CPS with components,

contracts, and equations, for analysis based on simu-

lation, model checking, model-based safety analysis,

for synthesis of HW/SW deployments, fault detection

and recovery, planning, and for many more function-

alities. We anticipate that the platform’s user commu-

nity will integrate more tools and models over time.

Models and services will be presented to the user

in catalogues, where the users will choose the tool, the

kind of analysis they want to try, and existing models

associated with it to exemplify the usage. The HUB-

CAP Platform will create a dedicated sandbox with

the tool already installed and the desired models ready

to be used. The user will follow the instructions to

perform the analysis on the chosen model. The users

will be able to write their own models and test the ca-

pabilities of the tool. If needed, the users will be able

to get support by the tool experts via the collaboration

services of the Platform.

4.1 Model Catalogue

We expect that users will supply adaptable and

generic models to assist newcomers with speciﬁc

A Cloud-based Collaboration Platform for Model-based Design of Cyber-Physical Systems

267

modelling tools and tool combinations. The Model

Catalogue will support access to these. Initially, we

expect to include models from standards and tutori-

als. For example, we expect to include all the public

models that are available for the INTO-CPS tool chain

(Mansﬁeld et al., 2017) that can be imported and used

directly inside the tools. Other example would in-

clude the wheel braking system architecture and the

related fault trees described in the AIR6110 standard

(S-18 Aircraft and Sys Dev and Safety Assessment

Committee, 2011) and modelled in (Bozzano et al.,

2015). A depiction of the current available models in

a Cloud Sandbox prototype is shown in Figure 3.

4.2 MBD Services

In the following we provide examples of tools and ser-

vices that may be realised using the HUBCAP Plat-

form. To provide further detail in the conceptualisa-

tion of the sandbox service, we organise the examples

by the kind of sandbox deﬁned in Section 3.

Example of a Demo Sandbox. Controllab Products

is a tool provider SME. Among other products that

may be hosted in other kinds of sandboxes, they pro-

vide pay-as-you-go access to virtual reality 3D anima-

tions of model’s simulations. The animations require

high-end computer speciﬁcations and specialised VR

hardware. In such cases hosting the experiments on a

remote sandbox hosted on the HUBCAP Platform is

neither feasible nor desired. Thus the sandbox may

provide a simple web application with highlights of

the full content and provide pointers to the replication

of the experiment environment on an adequate hard-

ware setup.

The Container Example. BEIA Consult is an SME

that has developed models and a tool applied in en-

ergy efﬁciency of smart buildings (Suciu et al., 2019).

The application is containerised using an open source

platform, i.e. the tool is stored in containers/software

packages that are run by a platform/container orches-

tration software such as Docker. Therefore, a sandbox

with a single V.OS hosting the container orchestration

software is available to execute the tool and models.

The Cloud Example. In this case a combination

of Linux-based tools and Windows-only tools can be

used to edit/display model details and generate Func-

tional Mock-Units (FMUs). The FMUs may then be

used to perform a co-simulation, the simulation of

the behaviour of the joint executions of the differ-

ent models. The co-simulation experiment may run in

a third virtual machine hosting a containerised/cloud

version of the INTO-CPS co-simulation tool (Ras-

mussen et al., 2019). Although the INTO-CPS tool

could be run in a single V.OS to perform a simulation

of diverse models, the access to the edition and visu-

alization of the models requires other tools, which is

a feature that makes the INTO-CPS tool a good ﬁt for

the Cloud Sandbox service level.

5 OPEN CALLS

To encourage the population of the platform, and to

evaluate its use as an aid to innovation in CPS design,

HUBCAP will run a series of funded Open Calls.

These will provide ﬁnancial and technical support for

SMEs to join the HUBCAP ecosystem and to experi-

ment in highly innovative, cross-border experiments.

There are three series of calls, each with different pur-

poses:

PULL Calls. “PULL” calls encourage the popula-

tion of the platform by model and tool suppliers.

SMEs may request awards (up to e1,000) to aid in

covering the costs of integration into the platform, in-

cluding participation in a one-day workshop and 3 –

4 days overall effort. There will be ﬁve such calls and

we expect to sponsor 200 projects.

EXPERIMENT Calls. “EXPERIMENT” calls

will support consortia of typical two SMEs to experi-

ment with the adoption of MBD for CPSs using assets

and services from the platform, in particular from

SMEs with less prior digital experience. Consortia

may bid for e30,000 - e75,000 for projects of 4 to 6

months duration. There will be two EXPERIMENT

calls and we expect to fund 20 to 30 projects.

INNOVATE Call. One INNOVATE call will fund

up to e200,000 for consortia of SMEs to deploy new

products and demonstrate highly innovative collabo-

rations using the HUBCAP Platform. Funding sup-

ports a project of 12 months’ duration. There will be

one such call and we expect to grant 10 projects.

According to (De Prato et al., 2015), 63% of high

potential innovations arise within projects in their ﬁ-

nal stages and 41% of all organisations behind these

are SMEs. Therefore, as it is expected that new in-

novations will emerge towards the third year from the

project third-party experiments, the EXPERIMENT

and INNOVATE calls are supplied with a larger bud-

get and are open later in the project timeline. Con-

versely, the PULL call is open from early in the

project (with ﬁve regular deadlines) and has a smaller

SIMULTECH 2020 - 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

268

Figure 3: Depiction of already available HUBCAP Platform models, which are presented to a user of the Cloud Sandbox

prototype developed so far.

(a) The landing page presented to a user by the

current prototype of the Cloud Sandbox.

(b) A Cloud Sandbox loaded with a tool and a

Workcraft Petri net model running.

Figure 4: Snapshots from the current Cloud Sandbox prototype.

budget dedicated to workshops helping partners get

their assets into the collaboration platform.

6 CONCLUDING REMARKS AND

FUTURE WORK

The HUBCAP Platform is under development, and

we expect that the ﬁrst public version will become

available in late 2020. Initial snapshots of its sand-

boxing prototype are available (Figure 4). The plat-

form is intended to form a shared resource for an

ecosystem in which diverse organisations will supply

models and tools to encourage and ease the evaluation

and adoption of MBD approaches for CPSs.

Our hope is that the HUBCAP ecosystem sup-

ported by this platform might encourage develop-

ment of MBD through servitisation, enabling users

and tool suppliers to explore, share, and buy CPS as-

sets (models, tools, services, training) from across the

ecosystem through a “test-before-invest” sandbox and

– at least in some cases – integrated “pay-as-you-go”

charging.

We anticipate that, in the course of populating the

collaboration platform, we will run into limitations in

the capabilities of both tools and the sandbox archi-

tecture. It is envisaged that there will be challenges in

regards to both licenses for OSs as well as tools with

special needs for particular hardware support (e.g.,

graphics cards) that may not easily be supported in

a sandbox context.

Despite the challenges, we hope that the HUB-

CAP Platform will be extended in several directions

A Cloud-based Collaboration Platform for Model-based Design of Cyber-Physical Systems

269

enabling true collaboration between different partici-

pating organisations, alongside and as a result of the

open calls. We envisage that the HUBCAP Platform

may be conveniently hosted at standard cloud oper-

ators as well as on servers at large companies with

many suppliers such that they can be in full control

of the development of the collaboration around larger

CPSs such as automobiles and airplanes.

ACKNOWLEDGEMENTS

The work presented here is partially supported by the

HUBCAP Innovation Action funded by the European

Commission’s Horizon 2020 Programme under Grant

Agreement 872698. We would also like to thank

Giuseppe Veneziano for his input and snapshots of

the Cloud Sandbox prototype, and Nick Battle, Clau-

dio Gomes and the reviewers for their comments on

drafts of this paper.

REFERENCES

Beckers, J., Heemels, M., Bukkems, B., and Muller, G.

(2007). Effective industrial modeling: The example

of happy ﬂow. In Heemels, M. and Muller, G., ed-

itors, Boderc: Model-based design of high-tech sys-

tems, chapter 6, pages 77–88. Embedded Systems In-

stitute, Den Dolech 2, Eindhoven, The Netherlands,

second edition.

Blochwitz, T. (2014). Functional Mock-up Interface for

Model Exchange and Co-Simulation. https://www.

fmi-standard.org/downloads.

Bozzano, M., Cimatti, A., Pires, A. F., Jones, D., Kim-

berly, G., Petri, T., Robinson, R., and Tonetta, S.

(2015). Formal Design and Safety Analysis of

AIR6110 Wheel Brake System. In CAV, pages 518–

535.

Cook, N. (2008). Enterprise 2.0: How social software will

change the future of work. Gower Publishing Limited.

De Prato, G., Nepelski, D., Piroli, G., et al. (2015). In-

novation Radar: Identifying Innovations and Innova-

tors with High Potential in ICT FP7, CIP & H2020

Projects. Science and Policy Report, Joint Research

Centre.

Fritzson, P. (2015). Principles of Object-Oriented Modeling

and Simulation with Modelica 3.3: A Cyber-Physical

Approach. IEEE Press. Wiley, 2 edition.

Gomes, C., Thule, C., Broman, D., Larsen, P. G., and

Vangheluwe, H. (2018). Co-simulation: a Survey.

ACM Comput. Surv., 51(3):49:1–49:33.

Jomaa, N., Nowak, D., Grimaud, G., and Hym, S. (2018).

Formal proof of dynamic memory isolation based on

mmu. Science of Computer Programming, 162:76–92.

Kainz, O., Jakab, F., Michalko, M., Hud

ak, M., and Petija,

R. (2019). Enhanced approaches to automated mon-

itoring environmental quality in non-isolated thermo-

dynamic system. IFAC-PapersOnLine, 52(27):365–

376.

Larsen, P. G., Fitzgerald, J., Woodcock, J., Fritzson, P.,

Brauer, J., Kleijn, C., Lecomte, T., Pfeil, M., Green,

O., Basagiannis, S., and Sadovykh, A. (2016). Inte-

grated Tool Chain for Model-based Design of Cyber-

Physical Systems: The INTO-CPS Project. In CPS

Data Workshop, Vienna, Austria.

Macedo, H. D. and Touili, T. (2013). Mining malware

speciﬁcations through static reachability analysis. In

European Symposium on Research in Computer Se-

curity, pages 517–535, Berlin, Heidelberg. Springer,

Springer Berlin Heidelberg.

Mansﬁeld, M., Gamble, C., Pierce, K., Fitzgerald, J., Foster,

S., Thule, C., and Nilsson, R. (2017). Examples com-

pendium 3. Technical report, The INTO-CPS Project.

Rasmussen, M. B., Thule, C., Macedo, H. D., and Larsen,

P. G. (2019). Migrating the INTO-CPS Application to

the Cloud. In Gamble, C. and Couto, L. D., editors,

The 17th Overture workshop, pages 47–61, Porto,

Portugal. Newcastle University Technical Report Se-

ries. CS-TR-1530.

S-18 Aircraft and Sys Dev and Safety Assessment Commit-

tee (2011). AIR 6110, Contiguous Aircraft/System

Development Process Example. Standard, SAE Inter-

national.

Suciu, G., Istrate, C., Petrache, A., Schlachet, D., and

Buteau, T. (2018). On demand secure isolation us-

ing security models for different system management

platforms. In Advanced Topics in Optoelectronics,

Microelectronics, and Nanotechnologies IX, volume

10977, page 109770R. International Society for Op-

tics and Photonics.

Suciu, G., Necula, L., Iosu, R., Usurelu, T., and Ceaparu,

M. (2019). Iot and cloud-based energy monitoring and

simulation platform. In 2019 11th International Sym-

posium on Advanced Topics in Electrical Engineering

(ATEE), pages 1–4. IEEE.

Sztipanovits, J., Bapty, T., Neema, S., Koutsoukos, X., and

Jackson, E. (2015). Design Tool Chain for Cyber-

physical Systems: Lessons Learned. In Proceedings

of the 52nd Annual Design Automation Conference,

DAC ’15, pages 81:1–81:6, New York, NY, USA.

ACM.

Van der Auweraer, H., Anthonis, J., De Bruyne, S., and

Leuridan, J. (2013). Virtual engineering at work: the

challenges for designing mechatronic products. Engi-

neering with Computers, 29(3):389–408.

SIMULTECH 2020 - 10th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

270