CISL - Core Insurance Service Layer

57
CISL - Core Insurance Service Layer Michael Ilger and Michael Halwax AMOS Austria, 1140 Wien, AUSTRIA, WWW home page: https://www.allianz.at Abstract. Core Insurance Service Layer (CISL) is a project to create a common but extensible service layer catalog for insurance processes. It follows the REST principles to define services and a datamodel which are exposed by new or existing insurance backends and that can easily be consumed by front end applications. The project provides a REST Meta-Model and tools to facilitate the adaption of CISL and the reuse across organizational units within Allianz. Keywords: API, REST, Insurance, Model 1 Introduction Large corporation, such as Allianz Insurance, want to standardise processes, software and infrastructure to benefit from synergies [11]. Allianz wants to give customers continuity in the user interfaces they see and to enable sharing of user interface components among dierent countries. To achieve this a project to create an abstraction layer called Core Insurance Service Layer (CISL) was initiated. The project has the goal to define reusable data objects and operations focussed on the insurance world, while also oering concepts and tooling which can be applied in other scenarios. Unlike many other standards which are based on SOAP, this service layer uses REST services. The idea behind this is to use some features which are important aspects of HTTP and REST, therefore making the whole process more suitable for the main goal: providing a fast and easy way to provide fresh user interfaces to existing back end applications and scaling them out vertically. To get a better perspective on the dierence between this approach and existing solutions such as BiPro [13] or Acord [14], it is very important to focus on the goals. While the two aforementioned standards rely on SOAP and the concept of larger service calls, the concept of REST allows us to put a much stronger emphasis on smaller resources and the connection between those. This leads to a scenario, where we can have reuse of individual resources and still provide simple, dynamic integration. 2 Project Organization and Outcomes The original idea for the project started in 2013, when a couple of Allianz entities were faced with a problem: They had to provide a new user interface based on

Transcript of CISL - Core Insurance Service Layer

Page 1: CISL - Core Insurance Service Layer

CISL - Core Insurance Service Layer

Michael Ilger and Michael Halwax

AMOS Austria, 1140 Wien, AUSTRIA,WWW home page: https://www.allianz.at

Abstract. Core Insurance Service Layer (CISL) is a project to createa common but extensible service layer catalog for insurance processes.It follows the REST principles to define services and a datamodel whichare exposed by new or existing insurance backends and that can easilybe consumed by front end applications. The project provides a RESTMeta-Model and tools to facilitate the adaption of CISL and the reuseacross organizational units within Allianz.

Keywords: API, REST, Insurance, Model

1 Introduction

Large corporation, such as Allianz Insurance, want to standardise processes,software and infrastructure to benefit from synergies [11]. Allianz wants to givecustomers continuity in the user interfaces they see and to enable sharing ofuser interface components among di↵erent countries. To achieve this a projectto create an abstraction layer called Core Insurance Service Layer (CISL) wasinitiated. The project has the goal to define reusable data objects and operationsfocussed on the insurance world, while also o↵ering concepts and tooling whichcan be applied in other scenarios.

Unlike many other standards which are based on SOAP, this service layer usesREST services. The idea behind this is to use some features which are importantaspects of HTTP and REST, therefore making the whole process more suitablefor the main goal: providing a fast and easy way to provide fresh user interfacesto existing back end applications and scaling them out vertically.

To get a better perspective on the di↵erence between this approach andexisting solutions such as BiPro [13] or Acord [14], it is very important to focuson the goals. While the two aforementioned standards rely on SOAP and theconcept of larger service calls, the concept of REST allows us to put a muchstronger emphasis on smaller resources and the connection between those. Thisleads to a scenario, where we can have reuse of individual resources and stillprovide simple, dynamic integration.

2 Project Organization and Outcomes

The original idea for the project started in 2013, when a couple of Allianz entitieswere faced with a problem: They had to provide a new user interface based on

Page 2: CISL - Core Insurance Service Layer

2

some new corporate identity and they had to already prepare the migration toa new insurance system. The new insurance system would already provide auser interface, but this would not be usable with their legacy systems, so thiswould mean two separate migration steps and possibly also three separate userinterfaces in a very short time.

Shortly after that, in early 2014, the project was started with a CISL im-plementation based on the Allianz Business System (ABS). ABS is a softwareplatform for insurance backends and is developed by Allianz in Austria. ABSis used world wide, as part of a plan to provide standardised software and pro-cesses for insurances. The focus of the project is allow to have a separationbetween the user interface and the underlying logic. Originally the project teamwas sta↵ed with three developers and analysts from the pool of AMOS (AllianzManaged Operations and Services) Austria resources working on the insurancesystem ABS. Soon the project was split into a separate entity dealing with thestandardisation of the interfaces and therefore also giving other systems moreinfluence on the development of the standard. A second unit, part of the ABSdevelopment team, continues to implement the interfaces defined by the CISLteam.

As of 2016 many di↵erent countries, including Austria, Switzerland, Italyand many more, have CISL in their road map, while Austria already has animplementation based on CISL in production.

3 The Integration Scenario

The general integration scenario surrounding CISL is relatively simple. It willseparate a back end system from the front end system. One of the main ideasbehind this is, that those two systems will evolve at di↵erent speeds. Especiallyin banking or insurance companies the underlying ’systems of record’ generallyevolve rather slowly, the reason for that being the stability of the system andthe fact that the sheer size of systems do not allow an quick rewrite.

While it generally is not considered a problem if the underlying logic runs onand older system (as long as software and hardware updates are still available),this is not true for user-facing front ends. While there are still some expert sys-tems around using traditional host-style text input, these systems are gettingfewer and acceptance for such solutions is going down. End customers expecteven more than that and modern client side javascript applications provide us-ability and customer experience which is muss better than anything which waspossible in the past - and all that across a variety of di↵erent types of devices.

Being able to focus on the front end alone and not having to deal with detailsof specific business logic allows you to create new user interfaces at a fraction ofthe cost and faster than previously. CISL allows you to do exactly that, as canbe seen in figure 1.

The central part of figure 1 represents the core of the API, creating an ab-straction between front end and back end systems. While the implementation ofthe services on the insurance platform is out of scope for now, we want to focus

Page 3: CISL - Core Insurance Service Layer

3

Fig. 1. CISL Consumer Producer

on the UI side. The first approach for a solution like this would be to carry thestructure provided by the CISL interfaces all the way to the user interface, butthis creates a couple of new problems: Unnecessary data transfer to the client,potential security problems due to wide open public interfaces and other securityor performance concerns.

The solution for this is to provide a complete application, called CISL appli-cation in figure 1, which consists of a server side element and a client side element.Those two elements are tightly coupled and are not using any standardised com-munication format, besides the general concept of HTTP and REST which isalso typically followed here.

4 Challenges

The project deals with a couple of di↵erent topics which have been around fora long time in academia and in practice. Starting with the data standardisationpoint of view, there is the important question about how individual resourcesand services are cut and then the follow up question regarding how they can beextended. These problems existed back when EDIFACT (with a syntax basedon separator characters) was created, existed when XML-based standards were

Page 4: CISL - Core Insurance Service Layer

4

created and still exist today. The goal is to create elements which are highlyreusable, but still leave room for customisations if needed - even if too muchcustomisation leads to fragmentation and therefore can destroy a standard.

One very simple example of cases where you need to be able to deal withdi↵erent systems which handle data di↵erently would be ’gender’. Traditionallysupporting exactly two values here would be enough, but there are movementswhich go towards allowing more than those two traditional values. Even if theunderlying standard supports more than the two traditional values, it does notmean that all the systems implementing this standard also support all the valuesand that a front end system should support all those values.

5 The REST Metamodel

As CISL is used in the context of multiple platforms and shared among stake-holders with various skill levels. The project decided to use a metamodel thatserves as a common base for communication between business analysts and de-velopers. This model defines the abstract syntax, the possible elements and therelations between them and is used as a base for model driven development [7].

Many frameworks that support the definition of REST APIs evolve. Promi-nent ones, that have also influenced CISL and it’s REST meta model, are Swag-ger [4], RAML [3] and WADL [5]. The CISL Project using an early version of ofRAML in 2014 1. Due to limitations in tool support, modularisation, expressingextensions and complex object oriented representations the project decided to in-troduce the meta models RADL (REST API Definition Language) and RCORE(based on EMF Ecore).

RADL and RCORE are based on the modelling framework EMF [9] and alsoprovide a textual representation based on Xtext [8]. The CISL model provides allthe information necessary to support the structural modelling of a REST API [1].In addition to the IDE integration (highlighting, code completion, validation) theproject provides a generator that is used for server-code generation and to createAPI user documentation.

With the use of Xtext it is possible to support IDE Integration like high-lighting, code completion, validation and code generation. To extend distributionpossibilities an export of the model to Swagger and Microsoft Excel is supportedas well in order to reach also developers as well as non-technical stakeholders.

Figure 2 describes a class diagram that gives an simplified overview of themost relevant RADL and RCORE model.

RCORE is an extension of Ecore and in its textual representation built on topof Xtext. It provides better support for annotations that may be used to specifyconstraints like datalists. A datalist is a list of options that are valid for a specificfield, that is determined via a REST call at runtime.

1 Since the RAML 1.0 (released in 2016), it provides initial support for object orientedrepresentations and new extension concepts.

Page 5: CISL - Core Insurance Service Layer

5

Fig. 2. RADL and RCORE

The listing 1.1 provides a sample in the RCORE textual representation thatdescribes EMF Ecore company package with a Company class.

Listing 1.1. Company package

package com . a l l i a n z . d i r e c t . company

import com . a l l i a n z . c i s l . base . Da t a l i s t

Page 6: CISL - Core Insurance Service Layer

6

c l a s s Company {S t r ing name

@Data l i s t ( Degree )

S t r ing [ ] degrees

}

RADL is based on WADL [5] but optimized for the integration with RCORE. Itprovides the means to define resources, methods, parameters and representationsthat are based on RCORE.

Listing 1.1 provides a sample RADL textual definition to get companies(based on an optional query parameter company name) and post a new companyon the collection resource defined by the path /companies .

package com . a l l i a n z . d i r e c t . r e s t

import com . a l l i a n z . d i r e c t . company .Company

r e s ou r c e s company

/companies | Companies {ge t | getCompanies ( query S t r ing companyName){

re turn Company [ ]

}post | postCompany (

Company company) {

re turn Company

}}

6 Workflows

Basically everything we do is based on workflows and interaction. Most dataexchange formats are based on the assumption that they are used for the inte-gration of (automated) systems and therefore also expects all the informationto be available from the start. When we think of a system based on user in-teraction this assumption does not work. Taking the relatively simple case of acar insurance shows us what types of information are required: The minimuminformation consists of at least one person (the owner; optionally also a driver orother roles), a vehicle and an underlying insurance product. In a user interface-driven scenario this means that you could end up first selecting a product, thenproviding the owner’s personal data and at the end choosing a car from a list.Having all this functionality combined in one single back end call would result inlimited customer experience as the user would have to fill out all the information

Page 7: CISL - Core Insurance Service Layer

7

first, before finding out that he is not allowed to buy this product due to agerestrictions. It would still be possible to duplicate the logic which checks for theage restrictions, but this would again cause heightened software maintenancecosts and reduce reusability. The approach taken here is to rely on somethingwhich has been around as long as the internet: Hyperlinks. While the anchor tagin HTML is a very central part of the web, there are no such standards for APIs,even though the concepts have been around for a while now in HATEOAS, orHypermedia as the Engine of Application State. This basically allows you to putmeta information into REST resources which points the consuming applicationinto di↵erent directions for a workflow. In case of our above example this meansthat the workflow could be specified in the following (simplified) way from aREST point of view

POST /quote - creates a new quote; this returns a quote object which couldalso be retrieved using a GET requests and the given ID (e.g. GET /quote/4711)

The resource representing that quote would also contain a section pointingto di↵erent other URLs specifying certain functionality. In our case this sectionwould also include the hint that a POST to /owner or a POST to /vehicle wouldbe allowed.

POST /quote/4711/owner - adds an owner to the quote created above. Thiscan subsequently be read or modified using other HTTP verbs.

A subsequent GET to the quote resource would now return a di↵erent result.The owner is already present, therefore the POST link to the owner would notbe o↵ered anymore.

The same concept would be used to create a vehicle in the next step, whichwould then leave the quote in a di↵erent state, where neither of the two linkswould be available anymore. Instead the resource could now show a couple ofdi↵erent links: Buy and Save.

It is important to remember here, that this is all done on the level of theunderlying API and not directly in the user interface. It would be better if theuser interface designer was already aware of the possible di↵erent actions thatare available, but generally it is not required to know all the possible steps inadvance. It is also worth noting that this would allow you to react to subtledi↵erences in workflows in di↵erent scenarios, where for example one systemwould require the owner to be entered first and one system would require thevehicle to be entered first.

7 Reusability and Extensibility

Though CISL API should be used as is, it important that it remains extensible(for example to adhere to national regulatory). CISL describes the common partsthat are designed and shared by the project team, but a partner may introducean extension module to support non global requirements. To extend the corethere are two possiblities:

– add new (sub)resources - introduce resource in parallel to the existing ones(the URI has to be unique)

Page 8: CISL - Core Insurance Service Layer

8

– inheritance - use inheritance in the representation, typically this approachwould be chosen when adding properties and having an is-a relation ship

The CISL API defines REST resources to expose core business functions (asdescribed in globally defined processes) that can be used in CISL Applications. Amajor challenge lies in finding the right granularity for the definition of resources:

If we design the API around fine grained resources, we would end upwith a chattier API for consumer applications. On the other hand, ifwe design the API based on very coarse grained resources (de-signed todo everything) there will not be enough variations to support all theAPI consumers’ needs and the API may become too di�cult to use andmaintain.[6]

Since various frontend specific requirements are expected, tailored interfaces,that would be hard to specify globally, are rarely used. This aligns with the goalto define a general interface that separates the fast evolving CISL applicationsfrom the stable and slow adapting core insurance platforms.

8 Conclusion

Overall the approach in CISL is to combine multiple di↵erent approaches intoone new framework, combining the advantages and prior art into one coherentsolution. This includes the definition of service calls based on REST instead ofthe more traditional SOAP-based web services which have been around for along time. Using REST brings two advantages with the typical format (JSON)being usually much smaller than XML messages [12] and with the full supportfor HTTP verbs and hyperlinking.

Two more topics, which still need more thorough work, are reuse and tooling.While it is very simple to define services which return some data, it is not thateasy today to describe their functionality as a model and use this as the basisfor actual implementations. In the recent past many new attempts were madeto find a good solution, but this is nowhere near the quality of such featuresin standards like XML Schema. These concepts of reuse of existing componentsas well as the possibility to extend the functionality, if the standard does notprovide everything that is needed, are the most important aspects of the futurework in this area.

References

1. Silvia Schreier. Modeling restful applications. In Proceedings of the Second Inter-

national Workshop on RESTful Design, WS-REST ’11, pages 15–21, New York, NY,USA, 2011. ACM.

2. Roy Thomas Fielding. REST: Architectural Styles and the Design of Network-based

Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.3. RAML - RESTful API Modeling Language, http://raml.org/, May 2016.

Page 9: CISL - Core Insurance Service Layer

9

4. Swagger, http://swagger.io/, May 2016.5. Marc J. Hadley. Web application description language (wadl). Technical report,Mountain View, CA, USA, 2006.

6. Prakash Subramaniam, REST API Design - Resource Modeling, http://www.

thoughtworks.com/insights/blog/rest-api-design-resource-modeling

7. Thomas Stahl, Markus Voelter, and Krzysztof Czarnecki. Model-Driven Software

Development: Technology, Engineering, Management. John Wiley & Sons, 2006.8. Lorenzo Bettini. Implementing Domain-Specific Languages with Xtext and Xtend.2013.

9. David Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. EMF:

Eclipse Modeling Framework 2.0. Addison-Wesley Professional, 2nd edition, 2009.10. Kuster, Jochen M. and Ryndina, Ksenia and Gall, Harald Generation of BusinessProcess Models for Object Life Cycle Compliance Business Process Management:5th International Conference, BPM 2007

11. Martin Grossman and Richard V. McCarthy and Jay E. Aronson E-CommerceAdoption in the Insurance Industry Issues in Information Systems, Volume V

12. Pavan Kumar Potti, Sanjay Ahuja, Karthikeyan Umapathy, and Zornitza Pro-dano↵ Comparing Performance of Web Service Interaction Styles: SOAP vs. REST2012 Proceedings of the Conference on Information Systems Applied Research

13. Brancheninstitut Prozessoptimierung, http://www.bipro.net14. Acord Data Standards http://www.acord.net

Page 10: CISL - Core Insurance Service Layer

ECIM: European Cloud Marketplace for Intelligent Mobility

Gorazd Marinic and Wim Vanobberghen

iMinds-SMIT, Vrije Universiteit Brussel, Belgium [email protected], [email protected]

Abstract. ECIM - European Cloud Marketplace for Intelligent Mobility brings to cities a platform that integrates a variety of mobility-related services, such as parking, shared bicycles and public transport, and allows developers to create multi-modal apps with seamless login, payment, discovery and use of different means of transport in the city. ECIM goes even further. It provides a base for development of new business models, such as Mobility-as-a-Service (MaaS).

Keywords: cloud platform; mobility; marketplace; parking; MaaS

1 Introduction

ECIM (European Cloud Marketplace for Intelligent Mobility) is a flexible, cloud-based solution for public and private sector actors who seek or provide web services to address mobility related needs of their cities. The Marketplace is a unique envi-ronment where service providers, data providers and developers come together and engage in co-design and co-creation of Mobility applications for citizens. To provid-ers the solution offers an effective distribution channel as well as opportunities to enter new markets and expand their user base. Developers, for their part, benefit from easy access to standardised APIs of different mobility services, some of which are available exclusively through the ECIM platform. The solution is indeed unique and as such has potential to revolutionise the way Mobility services are designed and de-livered to citizens. The aims of this paper are to (1) provide an overview of the ECIM project (2) discuss the encountered barriers and challenges during the project deploy-ment and resulting lessons learned and (3) to describe the identified avenues that can help ECIM remain sustainable in the long run while staying at the vanguard of the ongoing transport revolution.

Page 11: CISL - Core Insurance Service Layer

2 Project overview

ECIM (www.ecim-cities.eu) is an FP7 project, running between January 2014 and June 2016, with an overall budget of 4,384,000.00 EUR, with 50% of funding provid-ed by the European Commission. The 14 partners from come from 6 countries, and different backgrounds: academic, industry, public authorities and SMEs:

iMinds Belgium ESADE Spain IS-Practice Belgium ISSY MEDIA France Intrasoft Luxembourg 21C Consultancy UK Relational Greece CEN Group UK Mobile-for Belgium EJ Consultants UK BePark Belgium CIRB Belgium PayByPhone France ENoLL Belgium

The work has been divided between 7 inter-related work packages (WP), with Liv-

ing Lab as the overarching approach that engages all relevant stakeholders in each stage of the solution design, development, deployment, testing and evaluation. ECIM is currently in its final phase, and after successful piloting there is a proof-of-concept being run in Birmingham. Project partners are now focusing on dissemination of re-sults and working on a plan to make ECIM sustainable after the end of EC funding.

2.1 Objectives of the project

ECIM has three main objectives: allow cities and businesses to easily migrate ser-vices to the cloud, open cloud-based services to innovators for use as a basis for new services and facilitate easy access and cross-border adoption of cloud-based services across Europe. ECIM completes the value-chain for cloud-based public services by deploying a Marketplace wherein public authorities and the private sector, especially SMEs, can migrate their services, create new ones and find a market to sell them. To validate ECIM we selected mobility/parking, consistently cited as high priorities for citizens and public service providers alike. Commercial off-street and public sector on-street parking solutions are easy to locate online. However, these offerings func-tion in near total isolation from each other let alone with related areas such as public transport alternatives such as city bike stations. For example, merging real-time avail-ability of on-street and off-street parking with transport options would enable cities to advance ‘softer’ urban mobility priorities e.g. encouraging environmentally friendly modes of transport. To address these issues, ECIM delivers a cloud-based platform with functionalities that facilitate migration of existing data and services (APIs) of various mobility service providers and public entities (e.g. parking, public transport) and innovative creation of new ones. Moreover, we want to show that by enabling open and innovative management of mobility within cities, ECIM has the potential to significantly improve citizens’ lives by reducing congestion, lowering pollution and

Page 12: CISL - Core Insurance Service Layer

saving time. It also has the capacity to help cities save time and money by using cloud computing to stimulate development, aggregation and use of interoperable services that can be reused across borders.

2.2 Approach

To design a solution according to real end-user needs, ECIM relies on the proven Living Lab approach ensuring end-user involvement in all stages of development. The approach taken in analysing possible business models and developing a sustainability plan also relied on Living Lab-supported validation exercise. To validate the solution, we ran pilots in Barcelona, Issy-les-Moulineaux and Brussels, and a proof of concept in Birmingham. The platform was built based on collected requirements from project partners, and various APIs were integrated. A mobile app was developed for the pi-lots, which were able to share services among themselves to demonstrate cross-border interoperability of the solution. Tests were conducted in several iterations, to feed developers with feedback and test the app with incremental improvements. As its basic idea, ECIM is a platform that plays the intermediary role in a two-sided market. In order to create a realistic sustainability plan, various tasks were performed, from market to business model analysis and validation. Following the market analysis, business model analysis was performed and validated with project partners.

3 Main project outcomes

ECIM had specific goals in what concerns development of the technical solutions. Based on extensive user requirements collection and iterative development, the plat-form Marketplace is considered as a core project outcome. Piloting the test app, as a Marketplace service consumer, helped us to validate the integrated multi-modal ser-vices concept, and finally, the solution was complemented with a sustainability plan.

3.1 Platform Marketplace

The platform Marketplace, developed in WP3 [2], allows publishing a variety of data formats (CSV, JSON, XML), web services (REST), and complements the offer-ing with a single-sign-on and a single-payment mechanism. To publish its offerings, the service providers are presented with an interface that allows them to create an attractive presentation of his offering and provide full data / service details (e.g. end-point URL, methods, parameters), useful to a developer, who will subscribe to their offering. On the other hand, to consume a service a registered developer follows a procedure, where he needs first to subscribe to the desired service, and only when a data/service provider approves his request, he is able to access it. The Marketplace is analogous to common app stores, playing an intermediary role in terms of data/service discovery, subscription, technical interfaces (APIs), contractual, financial and legal agreements.

Page 13: CISL - Core Insurance Service Layer

3.2 Common API recommendations

While integrating various data and services from private and public providers, we encountered the need for more homogeneous interfaces. The idea of harmonising API formats, e.g. for a specific mobility domain (e.g. parking), stemmed from the efforts required to integrate a variety of different service provider APIs, which enable inter-action with similar services. As a solution, we proposed common API recommenda-tions initially for parking services (on-street and off-street) [2], and later we comple-mented these with a single-sign-on and a payment service. The initiative is promoted via www.smartmobility.io. The recommendations would first of all benefit develop-ers, who will need to get acquainted with only one format, and secondly the service providers, who would simply follow the existing implementations and would benefit from a large number of developers able to integrate their service with minimal effort.

3.3 Piloting

Tests demonstrated that the ECIM app was perceived as potentially useful for citi-zens and visitors [10]. This measure was evaluated the most positive, together with the concept underpinning ECIM. As such, ECIM app responds to the need to find relevant mobility information fast while on the move, and to interact with these ser-vices (start/end parking, pay tickets, etc.). Nonetheless, despite these positive points, the ECIM app did not manage to convince testers for further use. The reasons for this relate to the aspects of ease of use, content quality and accessibility of the app, which for some testers interfered with getting the relevant information fast and without prob-lems. Besides addressing strictly usability and design issues of the app, it became clear that integration is more than just adding services together and make them tech-nically fit. It involves also elaboration of a customer service around the fact of having the services combined both at the physical parking spot as well as on the app regard-ing crucial information. This cannot be done by the pilot test team alone, but requires the active involvement of all service providers. Nevertheless, the ECIM concept was positively evaluated, and the testers confirmed the need for such integrated apps, thus showing the platform idea is a valid one. In its final phase the piloting was comple-mented with hackathons and app challenges, which gave us the opportunity to vali-date the Marketplace and to use developers’ feedback to further improve the platform.

3.4 Advances beyond the state of the art

ECIM complements existing OpenData initiatives by providing not only data (e.g. points-of-interest), but also (web)services, which allow a developer not only to read, but to also interact with mobility service providers. As such, it goes beyond the con-cept of OpenData and provides the ground for OpenServices, where an authenticated and authorised developer in able to consume and monetize public and private ser-vices, up to now available only to providers themselves. ECIM creates a set of API format recommendations to increase service interoperability, help developers easily integrate new services in an app, and enable both sides exploit ECIM cross-border

Page 14: CISL - Core Insurance Service Layer

capabilities. With its central role, taking care of interaction between different parties, the Marketplace brings as one of the first the concept of the ‘app store’ to the Mobili-ty domain, paving way to development of Mobility-as-a-Service (MaaS) offerings.

3.5 Overall innovation potential

The innovation potential of ECIM lies in its open common APIs, which enables service providers, such as park operators, to easily publish their API to the ECIM Marketplace, where it immediately becomes available to registered developers. Since the developers need to visit only one Marketplace and choose from a variety of ser-vices, his development path is much smoother and quicker. The platform takes the role of an intermediary and lowers the discovery and negotiation cost because it takes over all technical, financial and contractual negotiations. A developer or a service provider is also able to combine different APIs and create new ones, and finally pub-lish them on the ECIM Marketplace. By providing this flexibility, ECIM gives devel-opers and service providers the tools to innovate not only in technical terms, but also on finding new ways to monetize their products and innovate in the business model.

3.6 References to related work and related projects

ECIM was built on the lessons learned in European Platform for Intelligent Cites (EPIC) project (2010-2013). ECIM also made use of lessons learned in other projects and initiatives: MOBI.Europe, SuperHub, POLITE, smartCEM, SATIE. As part of the requirements collection and technical design phase we explored several mobility-related initiatives, API services, Mobility apps, IoT and Mobile payments. During the project several commercial initiatives have emerged, and the ECIM team made sure the most important and relevant were studied and considered in the solution or con-cept design. Just to highlight one, MaaS, a concept emerged in 2015 in Finland, iden-tified as a paradigm shift, changing the way citizens, employees or travellers use Mo-bility services. ECIM is seen as a technical enabler for MaaS offerings, putting MaaS brokers on the map of potential customers.

4 Sustainability

4.1 Exploitation approach and expected impact

ECIM Marketplace enables SMEs to monetize their data and web services. With

strong value proposition for various groups of potential users, and a positive outcome of the market analysis, the project partners engaged in studying a feasible business model that would enable the project to become commercially viable and sustainable also after the funding from the EC has been concluded. Sustainability planning started with a market analysis [8], using desk research and tools such as SWOT analysis. We concluded that in an increasingly crowded market, ECIM needs to establish itself

Page 15: CISL - Core Insurance Service Layer

soon: manifold solutions exist or are being established that in one way or another mirror ECIM’s. MaaS plays a role in this regard, as more and more projects are focus-ing on it, rearranging boundaries of existing services. The competitive advantage of ECIM was identified as following. First, no other solution offers an online space for collaboration and co-creation of mobility services. Second, ECIM caters for ser-vice/data providers and developers – a box ticked only by one of the analyzed com-petitors, OneStopTransport. And third, the wide range of APIs ECIM offers to devel-opers. This leads to the realization that ECIM’s most promising potential lies in ena-bling MaaS initiatives by integrating various mobility services and offering them in an integrated and open fashion.

Strengths

• Enabling cooperation between service and data providers and developers

• Technological means to do so (APIs)

• Active interest and involvement of the public sector

Opportunities

• Popularity of MaaS concept and para-digm shifts in transport market entail-ing diverse business opportunities

• Involvement and investment from local, national and EU governments could secure leadership buy-in

Weaknesses

• Limited Marketplace participants

• As an EU project disincentives estab-lished mobility actors to invest

Threats

• Other actors (e.g. UbiGo) expanding into ECIM pilot cities

• Several competitors with similar offers

Table 1. SWOT Analysis

We continued exploring which business model could help ECIM enter this market and provide added value to its customers and become sustainable. ECIM business model relies on the platform theory, which is characterized by interdependencies of the participating groups of providers and consumers, and is conceptualized as a multi-sided market where the utility that user A derives from participating in the market is correlated to the number of users B (and conversely): externalities between stakehold-ers internalized by the market [4]. We initially studied the business model frameworks proposed in the literature, and started with business model canvas, proposed by Os-terwalder [9], which serves well to evaluate a single company. It is a chart that helps to visualize and clarify the essential parameters of a service or product: key partners, activities, resources; value proposition, customer segments, customer relationships, channels; cost structure and revenue streams. However, to provide a coherent treat-ment of the most relevant business model parameters, while at the same time empha-sising relationships between actors in an ecosystem setting, we decided to use another approach [1][5][7] to enrich the classic value chain approach in changing environ-ments such as online services where value is no longer created in a linear fashion. To

Page 16: CISL - Core Insurance Service Layer

determine the right answers to the above-described challenges and to produce a solid business plan for ECIM, a so-called LLAVA (Living Lab Assumption and VAlidation matrix) tool developed by iMinds-SMIT was deployed. It enabled us to discuss differ-ent business model aspects in a common framework, allowing to create and agree on a common vision on the different business model aspects and to manage and execute the innovation tracks by listing critical assumptions and mapping out validation steps. Finally, it supported us to assess the strength of the envisioned business model by pinning down focus, differentiation and coherency. We identified different business models, from transaction-based revenue sharing, to city-paid subscription, eventually following a public-private partnership. In all cases, the concept relies on large scale deployment, integration of many mobility services, playing the role of a central plat-form on which local players rely on and at the same time allowing new entrants -application developers, festival organisers and tourist service providers to exploit these services and provide more value to their existing offerings, e.g. full ticket-less city mobility during a music festival, or simply providing parking when renting a car.

4.2 Barriers and obstacles, and expected market value

Platform businesses have proven to be most viable in today’s Internet economy.

Nonetheless, to establish such a business, various roadblocks have to be overcome in the go-to-market strategy. The conclusion of the workshops suggested the need of city authority’s involvement in ECIM deployment in order to create impact. Establishing ECIM as a general service relying on revenue sharing would require a substantial business setup investment and more beneficial financial conditions to be attractive to service providers with existing payment processing contracts. Nevertheless, the main challenge is to start such two-sided market because the interdependencies on which such markets are founded pose substantial difficulties. Participating is only interesting for an actor if its counterparts also participate, and to launch such market is similar to the “chicken and egg” problem. This coordination problem (“hold up”) refers to the lack of incentives to invest for independent firms planning to offer complementary goods/services. Such problems (‘indirect network effects’) are argued to be “endem-ic” to the ICT industry [6]. Coordination problems lead in turn to incentives to bundle and to cross-subsidize complementary products and services, e.g. by using a so-called razor-and-blade or loss-leader revenue model. In such model one good (e.g. an inkjet printer, a video game console, or a razor) is sold below cost or is even free, while this cost is offset by revenues from sale of complementary goods [6]. In ECIM, users on one side of the market will only be attracted by the offer if there is desired content. The other side supplies content, which will in turn only be attractive to join for pro-viders if there are users. Several strategies theorize how to face this initial problem. Most importantly, pricing policies need to maximize the quantity of content providers on the one hand, and clients on the other. Cross-subsidization is necessary, as known from “freemium” offers [3]. The theoretical exercise, with the addition of the work-shops with project partners and discussions with third party providers, resulted in several pricing models and income streams being identified as realistic and attractive.

Page 17: CISL - Core Insurance Service Layer

5 Conclusion

The market analysis proved that there is room and demand for a solution such as ECIM, positive feedback on the concept was collected during the piloting, where testers (citizens) acknowledged the significant value of having several Mobility ser-vices integrated the one pilot app, which was developed using ECIM APIs. Further-more, the business model workshop showed that the identified value proposition is realistic, and the overall business model is feasible. Revenue sharing gets increasingly complex with an increasing number of actors involved. As a technological and con-tractual intermediary ECIM establishes rules for these relationships and simplifies the revenue sharing. This is the case also because certain kinds of service re-users will also be able to provide their own services on ECIM Marketplace at some point, thus changing role to provider; or even being both at the same time. Nevertheless, based on the amount of the estimated initial investment, and the identified barriers in becoming an attractive platform for service providers to share their revenue, we identified that the most feasible initial model is to provide the platform as a public infrastructure that is not per se profitable, but instead relies on low running cost enabled by its cloud nature, while maintaining the opportunity to switch to a paid, revenue sharing model once it gains popularity. Project partners are already discussing the possibility to provide the platform to Brussels region as regional infrastructure service, provided by CIRB and commissioned by the Brussels parking agency, which aims to harmonise and streamline parking services in the region.

References

1. Allee, V. (2009). Value-creating networks: organisational issues and challenges. The Learning Organisation, 16(6), 427–442.

2. Agiatzidou, E., Argyzoudis E., Zisis, G. (2015). D3.2 Architecture update and implemen-tation report, ECIM project deliverable. http://www.ecim-cities.eu/project/library

3. Anderson, C. (2009). Free: The Future of a Radical Price. Hyperion. 4. Armstrong, M. (2006). Competition in two-sided markets. The RAND Journal of Econom-

ics, 37(3), 668–691. http://doi.org/10.1111/j.1756-2171.2006.tb00037.x 5. Ballon, P. (2007). Business modelling revisited: the configuration of control and value. In-

fo, 9(5), 6–19. http://doi.org/10.1108/14636690710816417 6. Ballon, P. (2009). Network and Platform Economics. In Control and Value in Mobile

Communications. Faculteit Letteren en Wijsbegeerte — Vakgroep Communicatieweten-schappen, Vrije Universiteit Brussel. http://dx.doi.org/10.2139/ssrn.1331439

7. Bouwman, H., Haaker, T., & Vos, H. (2005). Designing Business Models: A Practical and Holistic approach. Telematica Institute Enschede.

8. Kogut, P., Rapacz, A. (2015). D7.5 ECIM Market Analysis. ECIM project deliverable. http://www.ecim-cities.eu/project/library

9. Osterwalder, A., Pigneur, Y., & Clark, T. (2010). Business model generation: a handbook for visionaries, game changers, and challengers. Hoboken, NJ: Wiley.

10. Vanobberghen, W., Veeckman, C., Satta, M., Iglesias, F., Kogut, P., Cross, S. (2015). D5.3 Periodical validation report – Brussels, Paris, Barcelona. ECIM project deliverable. http://www.ecim-cities.eu/project/library

Page 18: CISL - Core Insurance Service Layer

Software Testing Innovation Alliance

– the SHIP project –

Tanja E.J. Vos and Anna I. Esparcia-Alcazar

Open UniversiteitValkenburgerweg 177, Heerlen, The Netherlands

{tanja.vos}@ou.nlUniversitat Politecnica de Valencia

Camino de Vera s/n 46022, Valencia, Spain{tvos,aesparcia}@pros.upv.es

http://www.innovationalliance.eu

Abstract. The SHIP project is an Erasmus+ Knowledge Alliance whosemain goal is to strengthen the knowledge triangle between universities,Small and Medium Sized Enterprises (SMEs) and innovation support or-ganizations. The project entails to set-up of 4 Innovation Alliances in 5countries (Ireland + UK, Germany, Spain, Romania). The goal of thesealliances is to consolidate cooperation as a key feature of the knowledgeeconomy, reshaping traditional roles by multiplying outlets for universi-ties to generate direct economic impact from their work, and breakingdown barriers so that SMEs of all shapes and sizes can actively imple-ment academic-based innovation to boost their own competitiveness, andthat of the wider economy. One of the alliances is the Spanish SoftwareTesting Innovation Alliance, it is this alliance that is mostly describedin this showcase. The objective of this Alliance is to bring together keyactors in Spain on software testing in order to work together to improveinnovation support and technology transfer from universities to compa-nies in the area of software testing. The goal is to execute micro-projects,based on mutual needs, that induce small-step change having an impactin research, in practice, in business or in education. The final resultsbeing better software quality.

Keywords: Innovation, Software Testing, Technology Transfer, Smalland Medium Sized Enterprises

1 Information about the SHIP project

The SHIP project is an Erasmus+ Knowledge Alliance whose main goal is tostrengthen the knowledge triangle between universities, SMEs and innovationsupport organizations. In the following table we summarize the basic informa-tion about the project:

Page 19: CISL - Core Insurance Service Layer

Acronym SHIPName SME and Higher education institutes

in Innovation PartnershipsSource of funding Erasmus+ Knowledge Alliance

reference 554187-EPP-1-2014-1-IE-EPPKA2-KATotal funded budget 563.362 eurosDuraction December 2014 - December 2016Website http://www.innovationalliance.eu/

The project integrates seven key partners from six countries into the followingconsortium.

– Louth County Council, Ireland (coordinator)– Newry and Mourne Cooperative , United Kingdom– Mindshare Consulting, France– Canice Consulting, Ireland– The University Industry Innovation Network, The Netherlands– Universitat Politecnia de Valencia, Spain– Universitatea Politehnica din Bucurest, Romania– Univations, Germany

The consortium has been formed strategically to bring together all thosecompetencies and experiences needed to exploit the full value of the innovationalliances across Europe.

2 Objectives and expected outcomes of the project

The SHIP project will strengthen the knowledge triangle, by building sustain-able collaborative relationships between universities, Small and Medium SizedEnterprises (SMEs) and innovation support organizations. The goal is to buildsynergistic relationships between key stakeholders in the field of higher educa-tion and small enterprise to create a new culture of collaboration in innovationsupport.

This way, the project responds to the problem of increasing fragmentation inthe field of innovation promotion, especially the dislocation between those whogenerate knowledge that could spur innovation (universities), and those whocan translate that knowledge into marketable strategies and use it to produceeconomic growth (SMEs). The so-called notorious gap between university andindustry.

Few if any would dispute that successful transfer from academic results intoindustry is important. On the one hand, academic research activities shouldbe guided more towards the challenges companies face and solutions to theirimmediate problems. On the other hand, industrialist should help academics tovalidated their research results within a real industrial context. Academia andindustry obviously need each other and collaboration should be improved. Fordecades, many regional, national and international initiatives exists to try to

Page 20: CISL - Core Insurance Service Layer

Fig. 1. An illustration of the gap between universities and industry

close the gap. However, in the current days, successful collaboration still seemsto be di�cult to achieve and success stories are still something rare instead ofsomething normal. We keep talking about the gap (Fig 1) with industry on oneside and academia on the other. But we seem to be unable to even narrow it.

The SHIP project also focusses on this the gap with the objective narrow it.The project, however, takes a more pragmatic approach and entails, amongstothers, to set-up of 4 Innovation Alliances in 5 countries (Ireland + UK, Ger-many, Spain, Romania) The goal of these alliances is to consolidate cooperationas a key feature of the knowledge economy, reshaping traditional roles by mul-tiplying outlets for universities to generate direct economic impact from theirwork, and breaking down barriers so that SMEs of all shapes and sizes can ac-tively implement academic-based innovation to boost their own competitiveness,and that of the wider economy. The following alliances are being set-up:

1. The Regional Alliance in the Halle German region combines all importantstakeholder groups in connection with innovation and technology transferto create an action plan help to coordinate e↵orts and projects and createssynergies in the region.

2. The Cross-Border Alliance(Ireland-UK) is aimed at establishing how SMEscan access research and training from universities to bene�t in their business.

3. The Romanian Innovation Alliance whose goal is to foster green energy andsustainable products and services.

4. The 4th alliance is the Spanish Software Testing Innovation Alliance. Soft-ware testing is a prominent part of software development, and its e�cient

Page 21: CISL - Core Insurance Service Layer

automation if fundamental for any software company. In todays digitizedworld, software applications are mission-critical assets through which com-panies carry out their business.

Trends such as globalisation, standardisation and shorter life-cycles placegreat demands on the flexibility of the software industry. In order to competeand cooperate on an international scale, a constantly decreasing time to mar-ket and an increasing level of quality are essential. Testing is at the momentthe most important and mostly used quality assurance technique applied inindustry. However, the complexity of software and hence of their develop-ment amount is increasing. Modern systems get larger and more complex,as they connect large amounts of components that interact in many di↵er-ent ways and have constantly changing and di↵erent types of requirements(functionality, dependability, security, etc.). Data processing that impacts allaspects of our life is increasingly distributed over clouds and devices. Thisleads to new concerns to emerge, such as availability, security, and privacy.Consequently, the development of cost-e↵ective and high-quality systemsopens new challenges for industry that cannot be faced only with traditionaltesting approaches. New techniques for systematization and automation oftesting throughout the software and system life-cycle are being researchedby universities. We need to guarantee that these are successfully transferredto industry such they can keep up with the increasing quality requirements.

The rest of this paper will go into more depth about the status and resultsof this alliance.

3 The Software Testing Innovation Alliance

The objective of this Alliance is to bring together key actors in Spain on softwaretesting in order to work together to improve innovation support and technologytransfer from universities to companies in the area of software testing. Thisway we want to solve software testing problems, tackle challenges and removebarriers. The goal is to do this by executing micro projects based on mutual

needs that induce small-step change that has impact in research, in practice, inbusiness or in education. The final results being better software quality.

3.1 Mutual needs

Another emphasized aspect here is mutual needs. The alliance organizes events inSpain where Spanish academia and industry are brought together to brainstormand discuss how cooperation can improve innovation in software testing in Spain.Universities can elevator-pitch their R&D results on software testing indicating:what they have, how it can help companies and who has already used it suc-cessfully. SMEs on the other hand get a short time slot to explain their currentpractice on software testing and the problems, challenges and needs they have.

Page 22: CISL - Core Insurance Service Layer

After the presentations, speed-dating sessions re done such that every universityrepresentative meets up with each SME present.

After its launch in June 2015, the Spanish Software Testing Innovation Al-liance has organized 4 successful events in 4 di↵erent regions in Spain: Valencia,Andalusia, Aragon and Basque country.

3.2 Small-step change

Another of the emphasized aspects here is small-step. We do not pretend tohave a silver bullet, nor to finally close the gap between industry and university.During and through the meetings, we aim to detect the opportunity to do a micro(or even pico) initiatives that can start the the collaboration and technologytransfer immediately. Universities get the opportunity to evaluate their resultsin practice and companies get to try out something that might help them solvea problem or improve testing!

One of the success factors of this pragmatic approach is that these projectsare executed immediately within the context of the SHIP project. Consequently,barriers of looking for pre-financing are overcome and a short project is imme-diately executed to show the company whether the research results are worthanything to their practices or not. Then after this the company can better decidewhether continuing with this university collaboration is something they wouldbe willing to pay for.

During the 4 meetings we have compiled a list containing 15 micro-initiativesbetween 3 Spanish universities (Universidad Politecnica de Valencia, Universi-dad de Oviedo y Universidad de Sevilla) and 8 Spanish SMEs, 1 Spanish largecompany and 1 Dutch large company. At the moment 7 of these initiatives areexecuting, and the remaining 8 are in a very initial ‘”there is a will and interestto do it but we are not sure”-planning phase.

3.3 Impact! Whatever happens gives impact.

The last emphasis we put on impact in research, in practice, in business or in ed-ucation. The good news about the described approach is that whatever happenswe can count on impact. If we successfully transfer en university R&D resultsto a company, we have practice impact and even after a while business impactbecause quality of software products in the companies might have improved be-cause of the improved testing processes. For the universities a successful transfergives data that can be used to persuade others that he solution is worth trying.Even if the transfer is not successful and it cannot be used in the company ordoes not show to improve anything, we still have impact on research. Researchershave learned from the experience and might have more insight in: which parts oftheir solutions need more working; what directions need their research e↵ort goto solve the problems or challenges encountered in the transfer. Finally, estab-lishing contacts with companies interested in trying out the prototype tools ofthe universities, we have the chance to create interesting industrial projects for

Page 23: CISL - Core Insurance Service Layer

students (for example when needing to write their master thesis). This createdimpact in education.

3.4 Participants

The alliance is open to many di↵erent types of organisations:

– SMEs: the core of the alliance and main benefit of the adoption of innovationtesting methods and technologies in practice. To date we have 32 SpanishSMEs that are interested in the alliance, 8 of them are involved in micro-initiatives with a Spanish university.

– Academics: Software testing is a prominent part of software engineering re-search. E↵ective and e�cient software testing is fundamental. In todays dig-itized world, software applications are mission-critical assets through whichcompanies carry out their business, so research is needed in tools and tech-niques that can overcome the challenges. At this moment we have the follow-ing Spanish universities involved (the table also lists the transferable testingtechnology they have).

Universidad Politecnica de TESTAR Automated Testing at [8]Valencia the User Interface Level

TUNE-UP Agile testing tool [5]Universidad de Oviedo SQLRules [6]

SQLTest [7]Universidad de Sevilla Early Testing Methodologies [3]Universidade Da Coruna Property Based Testing [1]Universidad del Paıs Vasco Software Testing Data Analysis [2]Universidad de Malaga Search-based software testing [4]

– Large enterprises: have testing needs in order to develop and deploy de-pendable and secure critical software and may be users of di↵erent testingsolutions of the community.

– Developers of testing methods and tools: developers and researchers willhave access to di↵erent testing platforms and may share their knowledgeand advancements in the community.

– Public administrations: innovative testing solutions could lower the integra-tion, testing and maintenance costs of systems such as ones for managinghealthcare, social and environmental policies. In some specific domains, i.e.logistics / dangerous goods transportation, there are regulations at local,regional and national level. They may be involved to automatically generatetests that reduces bureaucracy.

– Standardization bodies: to establish international standards in di↵erent top-ics.

– Policy-makers: With the spreading of the digital economy on the Internet ofServices and Things that will involve all aspects of the citizens everyday lives,

Page 24: CISL - Core Insurance Service Layer

the dependability and security of services will become a must. We will raisethe awareness of the policy makers and evaluate the need or opportunity ofspecific regulations concerning testability and testing.

4 Expected outcomes of the project

During the execution of the project the micro-initiatives will be executed andthe impacts will be evaluated at the end of the project. Then after the projectwe will have the following results:

– A (virtual) community where news, events and general information may beshared among its members

– A repository of software testing results from academia which may be adoptedby industry

– A set of use cases where testing solutions have been transferred into industryin practice

– Lessons learned from transferring technologies from academia to industry.– A set of national contact points in order to promote face-to-face meetings in

di↵erent countries

Acknowledgements.

This work was financed by the the SHIP project (SMEs and HEIs in InnovationPartnerships) (reference: EACEA/A2/UHB/CL 554187).

References

1. Castro, L.M.: Advanced management of data integrity: property-based testing forbusiness rules. Journal of Intelligent Information Systems 44(3), 355–380 (2015),http://dx.doi.org/10.1007/s10844-014-0335-2

2. Dolado, J.J., Otero, M.C., Harman, M.: Equivalence hypothesis testing in ex-perimental software engineering. Software Quality Journal 22(2), 215–238 (2014),http://dx.doi.org/10.1007/s11219-013-9196-0

3. Escalona, M.J.: http://iwt2.org/actividad-grupo/investigacion/resultados/testing-temprano/

4. Ferrer, J., Garcıa-Nieto, J., Alba, E., Chicano, F.: Intelligent testing of tra�c lightprograms: Validation in smart mobility scenarios. Mathematical Problems in Engi-neering 2016 (2016), http://dx.doi.org/10.1155/2016/3871046

5. Letelier, P.: http://www.tuneupprocess.com/6. Tuya, J.: http://in2test.lsi.uniovi.es/sqltools/sqlrules/7. Tuya, J.: http://in2test.lsi.uniovi.es/sqltest/8. Vos, T.E.J., Kruse, P.M., Condori-Fernandez, N., Bauersfeld, S., Wegener, J.: TES-

TAR: tool support for test automation at the user interface level. IJISMD 6(3),46–83 (2015), www.testar.org

Page 25: CISL - Core Insurance Service Layer

MONDO: Scalable Modelling and ModelManagement on the Cloud

Dimitrios S. Kolovos1, Antonio Garcia-Dominguez1, Richard F. Paige1,Esther Guerra2, Jesus Sanchez Cuadrado2, Juan De Lara2,Istvan Rath3, Daniel Varro3, Gerson Sunye4, Massimo Tisi4

{dimitris.kolovos, antonio.garcia-dominguez, richard.paige}@york.ac.uk,{Esther.Guerra, Jesus.Sanchez.Cuadrado, Juan.deLara}@uam.es,{rath, varro}@mit.bme.hu, {gerson.sunye, massimo.tisi}@inria.fr

1University of York, United Kingdom,2Universidad Autonoma de Madrid, Spain,

3Budapest University of Technology and Economics, Hungary,4AtlanMod (Inria, Mines Nantes, LINA), France

Abstract. Achieving scalability in modelling and MDE involves beingable to construct large models and domain-specific languages in a system-atic manner, enabling teams of modellers to construct and refine largemodels in collaboration, advancing the state of the art in model queryingand transformations tools so that they can cope with large models (of thescale of millions of model elements), and providing an infrastructure fore�cient storage, indexing and retrieval of large models. This paper out-lines how MONDO, a collaborative EC-funded project, has contributedto tackling some of these scalability-related challenges.

1 Project Identity

– Project acronym: MONDO– Project title: Scalable Modelling and Model Management on the Cloud– Project partners: The Open Group (Project Coordinator), University of

York (Technical Coordinator), Autonomous University of Madrid, Universityof Nantes, Budapest University of Technology and Economics, IKERLAN,SOFTEAM, Soft-Maint, UNINOVA

– Website: www.mondo-project.org

– Project start date/duration: Nov 1, 2013 (30 months)

2 Introduction

As MDE is increasingly applied to larger and more complex systems, the currentgeneration of modelling and model management technologies are being stressedto their limits in terms of their capacity to accommodate collaborative develop-ment, e�cient management and persistence of models larger than a few hundredsof megabytes in size. As discussed in [1], achieving scalability in MDE involves:

Page 26: CISL - Core Insurance Service Layer

2 MONDO Consortium Partners

– being able to construct large models and Domain Specific Languages (DSLs)in a systematic manner;

– enabling large teams of modellers to construct and refine large models in acollaborative manner;

– advancing the state of the art in model querying and transformations toolsso that they can cope with large models (with millions of model elements);

– providing an infrastructure for e�cient storage, indexing and retrieval ofsuch models.

This paper discusses how the MONDO project has contributed to tacklingthese challenges. Section 3 provides an overview of the open-source MONDOplatform and then Sections 4–8 concentrate on each of the platform’s majorcomponents. Section 9 outlines the ongoing evaluation process and concludesthe paper.

3 Platform overview

The MONDO platform currently consists of the following components:

1. A framework (DSL-tao & EMF-Splitter) for automated development of scal-able Eclipse-based editors for DSLs;

2. Cloud-based (CloudATL) and Reactive (ReactiveATL) versions of the widelyused ATL model-to-model transformation language;

3. A new version of the VIATRA model transformation engine, built on areactive virtual machine architecture supported by the EMF-IncQuery in-cremental model query framework;

4. A framework for online and o✏ine collaborative modelling that supportsquery-based access control based on IncQuery queries and VIATRA trans-formations;

5. A framework for indexing of heterogeneous models stored in file-based ver-sion control repositories such as Git or SVN.

These components are then integrated into five classes of artifacts:

1. Cloud server nodes, which implement web service APIs that expose thecloud-based tools in MONDO, and may host “golden” and “front” SVN/Gitrepositories for collaborative modelling (further discussed in Section 8).

2. Cloud worker nodes for CloudATL-based model transformations.3. Eclipse workbenches, which include the Eclipse-based tools from MONDO.

Some of these tools invoke the cloud API.4. Standalone Java applications, which use the tools from MONDO as addi-

tional libraries that may invoke the cloud API.5. Other clients, which invoke the cloud API or use the web UI of the collabo-

ration framework.

Page 27: CISL - Core Insurance Service Layer

MONDO: Scalable Modelling and Model Management on the Cloud 3

Cloud frontends and Eclipse workbenches use OSGi to integrate the variouscomponents in MONDO in a controlled manner, ensuring they do not uninten-tionally interfere with each other and enabling their independent evolution be-yond the lifetime of this project. The cloud API is largely implemented in ApacheThrift (thrift.apache.org), an open source library for e�cient cross-languageRemote Procedure Calls and serialization. Figure 1 illustrates how these compo-nents are interconnected and organised internally. In the following sections, wefocus on the various ways in which the tools enable these integrations into theplatform.

Fig. 1. Architecture of the MONDO cloud platform

4 Heterogeneous Model Indexing Framework (Hawk)

Hawk [2] is a model indexing framework that can monitor large collections ofmodels stored in regular file-based version control systems (e.g. Git or SVN)and maintain a high-performance graph database with a snapshot of the latestversion of the models. Hawk can speed up advanced queries using its supportfor indexed and derived attributes, and the API is designed for managing itsconfiguration and querying the indexed models.

Hawk has been integrated with the rest of the platform in two ways: byintegrating new components into Hawk, and by developing compatibility layers

Page 28: CISL - Core Insurance Service Layer

4 MONDO Consortium Partners

so other tools can use Hawk with minimal changes. The main components ofHawk are:

– Client components: Hawk provides local and remote (Thrift-based) clientcomponents to manipulate Hawk indexes with the same UI.

– Model parsers: Hawk provides components that can parse Ecore XMI,Modelio XMI/EXML, IFC2x3 STEP/XML, IFC4 STEP/XML and BPMNmodels. The Ecore XMI component allows Hawk to index models developedusing the scalable modelling tools discussed in Section 7, produced by thetransformation engine outlined in Section 5, or developed collaborativelywith the framework presented in Section 8.

– Version control systems: Hawk provides components for monitoring localfolders, Git/SVN version control systems, workspaces and HTTP locations.The Git/SVN version control systems can be one of the “front” repositoriesmaintained by the collaboration framework discussed in Section 8.

– Backends: Hawk can use Neo4j or OrientDB for storing its graphs. Neo4jis the current market leader for graph databases, and OrientDB is anotherhigh-performance open source graph database with a more permissive licensethat simplifies redistribution in certain scenarios.

Hawk also provides abstractions that allow the tools developed in the otherwork packages to treat a local or a remote Hawk index as a standard EMF-compliant model, without requiring any changes. CloudATL can use Hawk in-dexes as the source of a transformation, IncQuery can query Hawk indexes andupdate the query results as their contents change, and DSL-tao can use a Hawkindex for faster discovery and editing of cross-file references.

5 CloudATL and ReactiveATL

CloudATL is an extended version of the ATL transformation engine that candistribute large-scale transformations over a Hadoop cluster of worker nodes.The engine operates in a transparent manner to the user, who does not need tohave any knowledge about distributed programming. The engine shares inputdata among the slaves, except for the the input model that is equally dividedamong them. The engine also relies on the MapReduce communication protocolsto aggregate the intermediate results and provide the final output model.

CloudATL can be submitted to a standard Hadoop cluster through theHadoop APIs as well as through standalone console-based tools. The latteruse a service-oriented API that turns a MONDO server into a frontend for adedicated Hadoop cluster. The API provides services to launch, monitor andstop CloudATL transformations on the Hadoop cluster, and CloudATL jobs canread remote Hawk indexes through the EMF resource abstractions mentionedabove. For validation and experimentation purposes, a virtualized Hadoop clus-ter (based on Docker1) has been made publicly available, and automated scriptsfor launching, stopping, and resizing the cluster are provided2.1https://www.docker.com/

2https://github.com/atlanmod/hadoop-cluster-docker/

Page 29: CISL - Core Insurance Service Layer

MONDO: Scalable Modelling and Model Management on the Cloud 5

Initial versions of CloudATL ran into scalability limitations of the stan-dard XMI model serialization format, especially the lack of support for con-current reads and writes. To solve this issue, a decentralized persistence backend(NeoEMF/HBase [3]) was developed and integrated with CloudATL. NeoEM-F/HBase is transparent to standard EMF tools, since it exposes its persistencefunctionality through the usual EMF interfaces. A persistence manager com-municates with the underlying data nodes through a persistence driver, andsupports a pluggable caching strategy. The design of the persistence managerdecouples the high level EMF-based code from the low-level data structures andcode accessing the database engine. Maintaining these uniform APIs between thedi↵erent levels allows including additional functionality on top of the persistencedriver by using the decorator pattern, such as di↵erent caching strategies.

NeoEMF/HBase o↵ers lightweight on-demand loading and e�cient garbagecollection. Model changes are automatically reflected in the underlying storage,making changes visible to all the clients. In the case of CloudATL, it guaranteesthat only the model elements needed to perform the partial transformation areloaded by each CloudATL worker. Moreover, NeoEMF/HBase has explicit sup-port for ACID properties. This allows the use of NeoEMF/HBase as a scalablepersistence backend for distributed and concurrent model transformations.

ReactiveATL3 is a reactive engine for the ATL transformation language. Itis designed to perform on-demand transformation in model-driven applications,by activating only the strictly needed computation in response to updates orrequests of model elements. Computation is updated when necessary, in an au-tonomous and optimized way by using incrementality and lazy evaluation.

6 IncQuery and VIATRA

VIATRA [4] is a reactive, event-driven and incremental model transformation

platform. It integrates IncQuery [5] as a graph query engine over EMF modelswith support for RETE-based incremental and local-search based query evalua-tion [6]. Within the MONDO project, initial support was provided for distributedincremental graph queries [7] deployed over a cloud infrastructure to scale com-plex graph queries for models with over 100 million elements.

Incremental queries enable to uniformly handle elementary model changes(e.g. change of an attribute) and aggregate model changes (e.g. disappearance ofa match in the query result set) as atomic events. To identify specific sequences ofsuch events, BME introduced complex event processing to model transformations

in VIATRA [8], which is especially suitable for streaming transformations [9].Reactive model transformations [4] following the paradigm of reactive pro-

gramming [10] may trigger reactions to atomic and complex events where rulescan be immediately fired upon certain changes are detected (live mode). Thisalso enables to incrementally chain multiple views and transformations [11].

MONDO partners collaborated to allow IncQuery to query Hawk indexesdirectly, and through the EMF resource abstractions of Hawk. An optimised

3https://github.com/atlanmod/org.eclipse.atl.reactive

Page 30: CISL - Core Insurance Service Layer

6 MONDO Consortium Partners

version of IncQuery was developed that can load only the part of the model thatis required. It accesses all instances of a type using direct edge traversal insteadof having to iterate through the entire model. The optimised version also passesthe Train Benchmark [12] test suite of the IncQuery implementation.

7 Scalable DSL Modelling Tools

DSL-tao [13] is a meta-modelling tool which enables the description of DSLsand their graphical modelling environments by means of patterns. It provides anextensible catalogue of recurrent patterns that can be instantiated to contributeto the DSL’s abstract syntax (e.g., typical domain patterns like state machinesor workflows, and meta-modelling design patterns like di↵erent realizations fortree-like data structures), the DSL’s concrete syntax (e.g., graphical or tabular)and infrastructure (i.e., functionalities of the modelling environment).

Of special relevance for scalability are infrastructure patterns related to DSLmodularity. While modularity mechanisms have been developed and are wellsupported for programming languages, this is not so for DSLs. In order to ob-tain more scalable DSL modelling tools, DSL-tao includes a modularity patternwhich permits customising model fragmentation strategies for DSLs. Hence, sim-ilar to how programming languages organize software projects, one can identifythe meta-model elements playing the roles of project, package and unit. The gen-erated modelling environment will then fragment and physically organize modelsinto packages (folders) and units (files) of smaller size, so that they can be moree�ciently managed. As an example, Figure 2 shows a modelling environmentthat instantiates the modularity pattern for wind-turbine models, enabling thedefinition of each subsystem in a di↵erent package, and its constituent compo-nents and state machines as files inside the package.

Fig. 2. Screenshot of generated DSL modelling tool supporting fragmented models.

The modularity pattern is realised by EMFSplitter [14], a framework thatgenerates domain-specific Eclipse-based model editors according to the defined

Page 31: CISL - Core Insurance Service Layer

MONDO: Scalable Modelling and Model Management on the Cloud 7

model fragmentation strategy. As a model is fragmented across the workspace,EMFSplitter needs an e�cient way to find candidate values for non-containmentreferences, according to a given scope. For this purpose, EMFSplitter relies onHawk. The final version of Hawk can monitor the generated local workspace andprovide e�cient local and global queries over the fragmented models.

The user only needs to open the Eclipse preferences page produced by EMF-Splitter and select Hawk to find candidate values for non-containment references(window labelled 1 in Figure 3). The next time that the EMFSplitter dialog forediting a non-containment reference is opened, the Hawk+EMFSplitter integra-tion will create a Hawk index (backed by OrientDB) that monitors over all themodels in the workspace, and will use it to e�ciently find the candidate values.The same index will be reused on later queries, and will be kept up to dateautomatically by Hawk.

1

2

Fig. 3. (1) EMFSplitter preferences page for selecting a component to find candi-date values for non-containment references. (2) EMFSplitter editor dialog for non-containment references.

The dialog for editing non-containment references is the same whether Hawkis used or not (window labelled 2 in Figure 3). Depending on the scope (workspace,project, package, or unit), Hawk will be used in a di↵erent way. In a first stage,Hawk will be queried to either find all the instances of the EType of the referenceacross the workspace, or find only the instances that are contained within a spe-cific project, package, or unit. In the second (and optional) stage, the retrievedinstances can be filtered by project nature.

Page 32: CISL - Core Insurance Service Layer

8 MONDO Consortium Partners

8 Collaboration Framework

The MONDO Collaboration Framework provides support for both online ando✏ine collaborative modeling scenarios by using graph queries for defining fine-

grained model-level access control policies and locks, and bidirectional modeltransformations to derive filtered views for each collaborator and to propagatechanges introduced in these views back to a server. The transformation uniformlyenforces high-level fine-grained access control policies during the derivation ofviews and the back-propagation of changes.

In an o✏ine collaboration scenario (see Fig. 4), models are stored in a gold

repository of an o↵-the-shelf version control system (VCS) that is not directlyaccessible by end users. Instead, the VCS server instead hosts a separate front

repository dedicated to each collaborator (group) that contains a copy of thegold repository filtered according to read access privileges of that user (usingthe get operation of the bidirectional transformation). This front repository ofthe user, which contains complete version history, can also be used to commit hischanges. Then the MONDO Collaboration Framework tries to propagate thesechanges to the gold repository (by a putback operation), but these changes maybe denied based on write permissions.

Fig. 4. Access control by bidirectional transformations (o✏ine collaboration).

In an online collaboration scenario, users can connect via their web browsersto open, view and edit models stored in the backends in live sessions. Multipleusers can collaborate on the same model simultaneously along the same accesscontrol policy (used for o✏ine collaboration as well). The editor is provided as anEclipse RAP-based web application, which can optionally be co-deployed withother server-side components. The main conceptual di↵erence with the o✏inecase is that the live detection of violating access control policies by incremental

Page 33: CISL - Core Insurance Service Layer

MONDO: Scalable Modelling and Model Management on the Cloud 9

queries. At the end of an online collaborative session, the result is persisted backin the VCS as in the o✏ine case.

Conflicting model changes need to be resolved by collaborators prior to asuccessful commit, which is carried out by search-based automated model merge

[15] where rule-based design space exploration [16] is used to search the spaceof solution candidates that represent conflict-free merged models. Our methodallows to easily incorporate domain-specific knowledge into the merge processto provide better solutions. The merge process automatically calculates multiplemerge candidates to be presented to domain experts for final selection.

9 Evaluation and Conclusions

In this paper we provided an outline of important scalability challenges in thecontext of MDE, and MONDO’s technical contributions for addressing them.MONDO has already contributed novel techniques and several prototype imple-mentations in all four identified key-areas. Currently, the research contributionsof MONDO are under assessment in the context of four industrial case studies.

The first case study (provided by UNINOVA4) comes from the constructiondomain and involves collaborative development and automated management oflarge computer-aided design (CAD) models of buildings. The second case study(provided by Soft-Maint5) involves exploration and automated regeneration ofcode from large models, which have been reverse-engineered from existing legacycodebases. The third case study (provided by IKERLAN6) involves multi-devicecollaborative development of models for o↵shore wind power generators, andthe fourth case study involves managing large collections of UML models cap-tured in a proprietary format supported by Softeam’s7 Modelio8 tool. To assessthe usefulness and impact of the technologies produced by MONDO, industrialpartners specified a set of concrete requirements and measures with reference toexisting state-of-the-art technologies during the first six months of the project.We intend to present the evaluation results in a follow-up publication as soon asthe evaluation reports have been produced by the respective MONDO partners.

References

1. Dimitrios S. Kolovos, Louis M. Rose, Richard F. Paige, Esther Guerra,Jesus Sanchez Cuadrado, Juan de Lara, Istvan Rath, Daniel Varro, Gerson Sunye,and Massimo Tisi. MONDO: scalable modelling and model management on thecloud. In Projects Showcase, pages 44–53, 2015.

2. Konstantinos Barmpis and Dimitrios S. Kolovos. Towards scalable querying oflarge-scale models. In Jordi Cabot and Julia Rubin, editors, Modelling Foundationsand Applications, volume 8569 of LNCS, pages 35–50. Springer, 2014.

4http://www.uninova.pt/

5http://www.sodifrance.fr/

6http://www.ikerlan.es/

7http://www.softeam.fr/

8https://www.modeliosoft.com/

Page 34: CISL - Core Insurance Service Layer

10 MONDO Consortium Partners

3. Abel Gomez, Amine Benelallam, and Massimo Tisi. Decentralized Model Persis-tence for Distributed Computing. In 3rd BigMDE Workshop, L’Aquila, 2015.

4. Daniel Varro, Gabor Bergmann, Abel Hegedus, Akos Horvath, Istvan Rath, andZoltan Ujhelyi. Road to a reactive and incremental model transformation platform:Three generations of the VIATRA framework. Software and Systems Modeling,2016. In press.

5. Zoltan Ujhelyi, Gabor Bergmann, Abel Hegedus, Akos Horvath, Benedek Izso,Istvan Rath, Zoltan Szatmari, and Daniel Varro. EMF-IncQuery: An IntegratedDevelopment Environment for Live Model Queries. Science of Computer Program-ming, 98, 2015.

6. Marton Bur, Zoltan Ujhelyi, Akos Horvath, and Daniel Varro. Local search-basedpattern matching features in emf-incquery. In Graph Transformation - 8th Int.Conf., ICGT 2015, L’Aquila, Italy, volume 9151 of LNCS, pages 275–282. Springer.

7. Gabor Szarnyas, Benedek Izso, Istvan Rath, Denes Harmath, Gabor Bergmann,and Daniel Varro. Incquery-d: A distributed incremental model query frameworkin the cloud. In ACM/IEEE 17th International Conference on Model Driven Engi-neering Languages and Systems, MODELS 2014, Valencia, Spain, 2014. Springer.

8. Istvan David, Istvan Rath, and Daniel Varro. Streaming model transformationsby complex event processing. In Juergen Dingel and Wolfram Schulte, editors,ACM/IEEE 17th International Conference on Model Driven Engineering Lan-guages and Systems, MODELS 2014, Valencia, Spain, 2014. Springer.

9. Jesus Sanchez Cuadrado and Juan Lara. Streaming model transformations: Sce-narios, challenges and initial solutions. In Keith Duddy and Gerti Kappel, editors,Theory and Practice of Model Transformations, volume 7909 of LNCS, pages 1–16.Springer Berlin Heidelberg, 2013.

10. Engineer Bainomugisha, Andoni Lombide Carreton, Tom Van Cutsem, StijnMostinckx, and Wolfgang De Meuter. A survey on reactive programming. ACMComputing Surveys, 2012.

11. Csaba Debreceni, Akos Horvath, Abel Hegedus, Zoltan Ujhelyi, Istvan Rath, andDaniel Varro. Query-driven incremental synchronization of view models. In 2ndWorkshop on View-Based, Aspect-Oriented and Orthographic Software Modelling(VAO 2014), pages 31:31–31:38. ACM, 2014.

12. Benedek Izso, Gabor Szarnyas, Istvan Rath, and Daniel Varro. MONDO-SAM: Aframework to systematically assess MDE scalability. In BigMDE 2014 2nd Work-shop on Scalable Model Driven Engineering, page 40. ACM, 2014.

13. Ana Pescador, Antonio Garmendia, Esther Guerra, Jesus Sanchez Cuadrado, andJuan de Lara. Pattern-based development of domain-specific modelling languages.In MoDELS, pages 166–175. IEEE, 2015.

14. Antonio Garmendia, Esther Guerra, Dimitrios S. Kolovos, and Juan de Lara. EMFsplitter: A structured approach to EMF modularity. In XM@MoDELS, volume1239 of CEUR Workshop Proceedings, pages 22–31. CEUR-WS.org, 2014.

15. Csaba Debreceni, Istvan Rath, Daniel Varro, Xabier De Carlos, Xabier Mendial-dua, and Salvador Trujillo. Automated model merge by design space exploration.In Fundamental Approaches to Software Engineering - 19th International Confer-ence (FASE 2016), volume 9633 of LNCS, pages 104–121. Springer, 2016.

16. Abel Hegedus, Akos Horvath, and Daniel Varro. A model-driven framework forguided design space exploration. Automated Software Engineering, 22:399–436,2015.

Page 35: CISL - Core Insurance Service Layer

adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011

SmartGov Advanced decision support for Smart Governance

Malgorzata Z. Goraczek*, Peter Parycek, MAS, MSc**

Donau-Universität Krems, Department für E-Governance, Dr.-Karl-Dorrek-Straße 30, 3500 Krems

*[email protected] **[email protected]

Abstract. The SmartGov project seeks to strengthen contemporary urban gov-ernance by offering decision support and two-way communication between citi-zens, governments and other stakeholders in (Smart) Cities. There is a huge, but underdeveloped potential of Linked Open Data and Social Media as crowdsourcing tools that complement regular data collection for decision-making. SmartGov will innovatively integrate these data sources with Fuzzy Cognitive Maps (FCMs), to enable quantitative modelling of complex problems and simulation of dynamic behavior of factors underlying these problems. Hence, decision-makers and citizens can effectively utilize (currently inaccessi-ble) Open Data, Social Media feeds and expert-based FCMs to simulate impacts of different scenarios and to improve two-way communication between gov-ernments and citizens.

Keywords: smart tools and services, smart data, linked open data, big data, so-cial media, smart governance, smart citizens, policy simulation, urban govern-ance, Fuzzy Cognitive Maps

1 Introduction

‘Smart Cities’ provide new ways of designing and managing public services, infra-structure, sustainable mobility, economic development and social inclusion. Two-way communication between citizens and urban policymakers is lacking strongly. This is partly the result of underutilization of citizens’ Social Media feeds and useful Open Data sets. The SmartGov project aims to create new support tools that effectively incorporate Linked Open Data and Social Media into Fuzzy Cognitive Maps (FCMs). FCMs will be used in the SmartGov project as a modelling and visualization tool for discussing policy scenarios between citizens and governments. The developed tools will be tested and implemented in four European cities. Limassol (Cyprus) and Quart de Poblet (Spain) are pilot cities and Vienna (Austria) and Amsterdam (Netherlands) are supporting cities.

Page 36: CISL - Core Insurance Service Layer

Table 1 below presents an overview of the main objectives, used methods and ex-pected results of the SmartGov project, which aims to offer advanced decision support tools for Smart Governance. Table 1: Project overview

Objectives

Methods

Expected results

Create new governance meth-ods and supporting ICT tools

Research on governance pro-cesses for urban planning and mobility

Fuzzy Cognitive Maps: Provide new decision methods, tools and guide-lines

Simulate impact of policies for urban planning in Smart Cities

Visualization & modelling of complex problems in Smart Cities

Increase transparency and trust through visualization of decision scenarios

Support two-way communica-tion with large stakeholder groups

Fuzzy Cognitive Maps: Linked Open Data & Social Media

Create knowledge and awareness for new policies of sustainable mobility

2 Funding & current status of the project

SmartGov is funded by JPI Urban Europe, a joint programming initiative. The aim of JPI Urban Europe is to create attractive, sustainable and economically viable urban areas for European citizens and communities. The strategy of JPI Urban Europe pur-suits to coordinate the research of Europe’s public funds: to transform urban areas into centres of innovation and technology; to realize eco-friendly and intelligent intra- and interurban transport and logistic systems; to ensure social cohesion and integra-tion; as well as to reduce the ecological footprint and enhance climate neutrality. [1]

The SmartGov project supports the goals of JPI Urban Europe through creating

new tools for the simulation of policies for urban planning in Smart Cities. SmartGov is funded with a total budget of 1.232.120 EUR. The project will last 3 years. It start-ed on the 1st April 2016 and will continue until the end of March 2019.

Further information is also available online under: www.jpi-urbaneurope.eu/smartgov

Page 37: CISL - Core Insurance Service Layer

3 Consortium

The consortium is an inter- and trans-disciplinary project team: 3 universities, 3 IT service & software engineering companies & 2 pilot cities - which combine different disciplines and knowledge.

3.1 Academic partners

The academic partners - Danube University Krems, TU Delft and Cyprus University of Technology - contribute with different research focus to SmartGov:

Danube University Krems is specialized in continuing education and applied re-

search. The Department for E-Governance conducts trans-disciplinary research on the effects of technological advances with regard to strategies, structure and processes in the digital network era. The team will contribute with its knowledge in the domains of E-Governance (E-Administration and Government), E-Democracy (E-Participation and Cooperation), Open Data (Information management and organizational change processes) and Data Protection Rights. Danube University Krems is the Project Coor-dinator of the SmartGov project.

TUDelft ranks amongst the top universities in the world in the field of technology.

SmartGov will be carried out at the Faculty of Architecture & the Built Environment, Department OTB - Research for the Built Environment. OTB specializes in academic research and policy advice in the field of housing, urban studies, sustainable energy and construction, mobility and transport, urban & regional planning, and GIS tech-nology. Delft University of Technology will lead the evidence review for the devel-opment of smart urban governance through integration of FCMs, Social Media feeds, and Open Data.

Cyprus University of Technology offers education and high-level research in lead-

ing branches of science and technology which have high impact on the economic, technical, and scientific sectors. Cyprus University of Technology is participating with the Software Engineering and Intelligent Information Systems research laborato-ry. The team will be responsible for developing the FCMs software tool and their interfaces with sources like social networks and linked Open Data.

3.2 Companies

3 IT service & software engineering companies companies – Active Solution, Interfu-sion and Kenus Informatica - combine a diverse range of backgrounds for the devel-opment, testing and implementation of SmartGov:

Active Solution AG is a leading software and engineering company. The company

implements large scale projects for multinational corporations. Its software develop-ment team will contribute the expertise for web development, Social Media, GIS,

Page 38: CISL - Core Insurance Service Layer

CAD and embedded systems for SmartGov. Their knowledge from FP7 in Social Media and its use in urban governance is essential for carrying out the project.

Interfusion Services Ltd has specific expertise in the field of information technolo-

gy and socio-humanities. The team supports the project in the important core areas such as e-learning, e-government and policy modelling, and most important: fuzzy cognitive modelling. Interfusion‘s major involvement in the SmartGov project will be within the development of the Fuzzy Cognitive Map software tool and its interfaces, as well as the realization of the piloting.

Kenus Informatica S. L. as an IT service company provides know-how in deliver-

ing IT services for city councils and other governmental organizations. Kenus will support the project through designing and validating the FCM interfaces. The team will support the technical training and will create according training material to all pilot cities (Limassol and Quart de Poblet) and the supporting cities (Vienna and Am-sterdam), as well as first-level support to these cities.

3.3 Cities

Two pilot cities are in the consortium, in which the FCM tolls will be tested and im-plemented:

Limassol (Cyprus) already participated in various projects dealing with local ener-

gy leadership (SUSREG [2], CONURBANT [3]) and with energy efficiency (FIESTA [4]). In the context of SmartGov Limassol will tackle organizational components that hinder resource-efficient governance, both in terms of citizen-municipality interaction and internal communication, moving to a paper-less pro-active governance model. The policy focus in SmartGov will be increasing energy awareness of citizens, em-ployees, and tourists.

Quart de Poblet (Spain) has a leading position among other public institutions in

Spain regarding Accessibility and Open Government. Aspects like the availability and access to updated information services about e.g. transport and mobility and infra-structures of the information are considered of high-priority. The focus of Quart de Poblet in SmartGov is to improve information accessibility with regard to transport and mobility.

Further, the project SmartGov is supported by the city of Vienna (Austria) and

Amsterdam (The Netherlands). The supporting cities will co-operate during the pro-ject with the aim to strengthen the knowledge base, networking and knowledge ex-change function of city government to achieve the common goals in the context of Smart Cities.

Page 39: CISL - Core Insurance Service Layer

4 Outcomes, tasks and deliverables

The whole project consists of 6 work-packages:

─ Work-package 1: Consortium Management ─ Work-package 2: Urban Governance and Urban Policy ─ Work-package 3: FCM Modelling ─ Work-package 4: Social Media for Governance ─ Work-package 5: Piloting ─ Work-package 6: Scientific Dissemination and Exploitation

4.1 Work-package 1: Consortium Management

The outcomes of work-package 1 will ensure the academic excellence, the coordina-tion of the technological progress, as well as administration of management tasks according to the work plan. Tasks and deliverables of work-package 1 consist of the control of the project stages and according reports. The overall project management method of the SmartGov project is PRINCE2 [5].

4.2 Work-package 2: Urban Governance and Urban Policy

The tasks of work-package 2 focus on the requirements for contemporary urban gov-ernance of smart cities: on the one hand based on an analysis with relevant stakehold-ers, on the other hand using a systematic evidence review. Further legal frameworks will be examined. The work-package also consists of monitoring and analysing stake-holder experiences with FCM models and its interfaces. Deliverables are reports cor-responding to these tasks.

4.3 Work-package 3: FCM Modelling

Work-package 3 will deliver specification documents for tasks related to the FCM tool and its interfaces - as designing, testing and implementing. Three releases will guarantee feedback loops for upgrades of technical and user requirements. The soft-ware development will be based on SCRUM [6], which allows flexibility to changing user requirements and unforeseen technical difficulties in R&D projects. The final deliverable consists of user and administration manuals for the developed FCMs tools.

4.4 Work package 4: Social Media for Governance

The tasks of work-package 4 focus on the development of an engine, which will col-lect information from Social Media, newspapers and blogs. Advanced tools will clus-ter and visualize information (e.g. sentiment analysis). Finally this engine will be integrated with the FCM tool. Specification documents for design, testing and imple-

Page 40: CISL - Core Insurance Service Layer

mentation, as well as three software releases are the main deliverables of this work-package.

4.5 Work-package 5: Piloting

The piloting work-package aims to monitor, assist and ensure that all pilots success-fully tackle a variety of pressing urban policy issues regarding different domains with the developed tools and their methodologies. The deliverables of work-package 5 will offer guidelines, execution documents and a final pilot evaluation report.

4.6 Work-package 6: Dissemination and Exploitation

The tasks of work-package 6 include dissemination of project findings of SmartGov to a wide audience of policymakers, practitioners and scientists in Europe, in particu-lar to actors related to pilot and support cities, national organizations and EU bodies. The deliverables consist of reports about strategy and activities of dissemination, communication & exploitation.

5 Market value, innovation and impact

5.1 Market value

The primary target groups for the SmartGov project tools are local governments, mainly in Europe. There are 8.512 cities in Europe and the research and development results are relevant to all of them. The strategy to reach them in an effective way builds on cluster organizations such as EUROCITIES (a network 130 of Europe's largest cities and 40 partner cities governing 130 million citizens across 35 countries), Major Cities of Europe, ICLEI, the European Metropolitan Network Institute (EMI), the European Urban Knowledge Network (EUKN) and business partners. SmartGov will connect with existing networks of national knowledge platforms, e.g. Platform 31 in the Netherlands, to maximize outreach and the impact of its results. 5.2 User-driven innovation

A profound principle applied in SmartGov is the understanding of stakeholders needs as a source and driver of the research and innovation process. This is referred to as user-driven innovation, where the crucial role of citizens in smart cities is taken into consideration. Their needs and demands will play an initial role during policy design and implementation.

Two-way communication between stakeholder groups will show the requirements for effective governance decisions, as well as their acceptance and effectiveness. In-novative ICT-driven networking of stakeholders will offer new and smart ICT deci-sion tools, based on Fuzzy Cognitive Maps.

Involving citizens and further stakeholders to participate in the policy decision making process enables and encourages citizens to exert political influence by affect-

Page 41: CISL - Core Insurance Service Layer

ing decision-makers through suggestions and feedback. Simulating various scenarios will lead to new knowledge about societal and economic needs regarding mobility and create awareness for new policies. SmartGov will show that citizens’ and stake-holder needs, suggestions and feedback are fundamental for decision-makers. This can increase trust in inclusive decision making.

Further SmartGov will foster equal rights for information by enabling the adminis-trative staff to more actively provide citizens with detailed information, thus encour-aging the latter to participate in decision-making processes.

5.3 Impact of novel methods based on Fuzzy Cognitive Maps

SmartGov aims to provide novel and proven methods, sustainable tools and guide-lines, which improve efficiency and effectiveness by simulating potential impacts of decision alternatives in urban planning for decision makers. SmartGov will be based on Fuzzy Cognitive Maps which integrate urban Open Data and a Social Media en-gine.

Further the Fuzzy Cognitive Maps tools will provide powerful visualizations of these simulated scenarios. Displaying scenarios - in an easy and comprehensible way - to decision-makers, but also to involved citizens and stakeholders represents an im-pact on equal rights for information, transparency and openness.

Acknowledgement

We would like to thank our project partners for the collaboration during the crea-tion of the proposal: Bettina Rinnerbauer (Danube University Krems), Reinout Klein-hans (TU Delft), Peter Sonntagbauer and Susanne Sonntagbauer (Active Solution AG), Haris Neophytou (Interfusion Services Limited), Vicente Penalver Camps (Kenus Informatica), Andreas Andreou (Cyprus University of Technology), Gilberto Martinez (Municipality of Quart de Poblet) and Evridiki Chrysostomou (Municipality of Limassol).

References

1. cf. Joint Programming Initiative Urban Europe, http://jpi-urbaneurope.eu /about/what/ 2. cf. SUSREG - Stimulating Sustainable Regional Development by means of a Structured

Process Approach, https://ec.europa.eu/energy/intelligent/projects/en/projects/susreg 3. cf. CONURBANT - An inclusive peer-to-peer approach to involve EU CONURBations

and wide urban , https://ec.europa.eu/energy/intelligent/projects/en/projects/conurbant 4. cf. FIESTA - Family Intelligent Energy Saving Targeted Action,

https://ec.europa.eu/energy/intelligent/projects/en/projects/fiesta 5. cf. AXELOS Limited, https://www.prince2.com/uk 6. cf. Scrum.org, https://www.scrum.org/Resources/What-is-Scrum

Page 42: CISL - Core Insurance Service Layer

MPM4CPS: Multi-Paradigm Modellingfor Cyber-Physical Systems

Hans Vangheluwe1, Vasco Amaral2, Holger Giese3, Jan Broenink4, Bernhard Schatz5,Alexander Norta6, Paulo Carreira7, Ivan Lukovic8, Tanja Mayerhofer9,

Manuel Wimmer9, and Antonio Vallecillo10

1 University of Antwerp, Belgium. ([email protected])2 Universidade Nova de Lisboa. Portugal. ([email protected])

3 University of Potsdam, Germany. ([email protected])4 University of Twente, The Netherlands. ([email protected])

5 Fortiss, Germany. ([email protected])6 Tallin University of Technology, Estonia. ([email protected])7 IST, Universidad de Lisboa, Portugal. ([email protected])

8 University of Novi Sad, Serbia. ([email protected])9 TU Wien, Austria. ({mayerhofer,wimmer}@big.tuwien.ac.at)

10 Universidad de Malaga, Spain. ([email protected])

Abstract. The last decades have seen the emergence of truly complex, designedsystems, known as Cyber-Physical Systems (CPS). Engineering such systems re-quires integrating physical, software, and network aspects. To date, neither a uni-fying theory nor systematic design methods, techniques and tools exist to meetthis challenge. Individual engineering disciplines, such as mechanical, electrical,network and software engineering offer only partial solutions.Multi-Paradigm Modelling (MPM) proposes to model every part and aspect ofa system, including development processes, explicitly, at the most appropriatelevel(s) of abstraction, using the most appropriate modelling formalism(s). Mod-elling language engineering, including model transformation, and the study oftheir semantics, are used to realize MPM. MPM is seen as an effective answer tothe challenges of designing Cyber-Physical Systems.Research on modelling CPS is typically based on national activities with looseinternational interaction. To establish an interdisciplinary and inter-institutionalplatform for scientific information exchange, consensus building, and collabora-tion, the COST Action MPM4CPS, funded by the EU Framework Programmefor Research and Innovation, has been initiated. MPM4CPS aims to develop andshare foundations, techniques, and tools related to Multi-Paradigm Modelling forCyber-Physical Systems (MPM4CPS) and to provide educational resources. Inthis paper we describe the overall MPM4CPS approach and its current status.

Keywords: Cyber-Physical Systems (CPS), Multi-paradigm Modelling (MPM),Model-Based Systems Engineering (MBSE), Multi-formalism, Multi-abstraction,(Co-)Simulation

Page 43: CISL - Core Insurance Service Layer

1 Basic Project Information

– Name and acronym: Multi-Paradigm Modelling for Cyber-Physical Systems(MPM4CPS)

– Project reference: ICT COST Action IC1404, Science Officer: Dr. Mafalda Quintas.– Budget: Approx. 120,000.00 EUR per year, Duration: 25/11/2014 - 24/11/2018– Project consortium:

⇧ 25 initial participating countries: Austria, Belgium, Bosnia and Herzegovina,Croatia, Czech Republic, Denmark, Estonia, France, fYR Macedonia, Ger-many, Greece, Hungary, Ireland, Italy, Netherlands, Norway, Poland, Portugal,Romania, Serbia, Slovenia, Spain, Sweden, Switzerland, and United Kingdom.

⇧ 3 recently joining countries: Israel, Latvia, and Turkey.⇧ 4 COST International Partners: Victoria University of Wellington (New Zealand),

Georgia Tech (USA), MathWorks (USA), and McGill University (Canada).– Official project web sites: http://www.mpm4cps.eu andhttp://www.cost.eu/COST_Actions/ict/IC1404

2 Background

In virtually any area of human activity, truly complex, designed systems, known asCyber-Physical Systems (CPS) [3], are emerging. These multi-disciplinary systemsdeeply integrate collaborating physical, software, and network parts.

The foundational infrastructure that is able to unify in a consistent way the plethoraof CPS facets is Multi-Paradigm Modelling (MPM) [1, 2, 4]. MPM is a research fieldfocused on breaking the inherent complexity of large-scale and complex systems intodifferent levels of abstraction and views (i.e., rigorous models of some physical or logi-cal reality), each expressed in an appropriate modelling formalism. By appropriate, notonly cognitive aspects (which impact learnability and usability of the formalism) aremeant, but also technical ones, such as tractability for debugging and analysis.

Modelling language engineering (using model transformations), and the study oftheir formal semantics, is used to realize MPM, by combining multiple models of com-putation such as continuous-time, discrete-event, and synchronous data flow. MPM,viewed as the logical continuation of Model-Based Systems Engineering (MBSE), isbecoming a successful approach by providing processes as well as software tools thatare able to combine, couple, and integrate each of the views that compose a system.The main goals are to analyse (for safety and reliability), to simulate (for optimizationpurposes) and, where appropriate, synthesize these systems.

Research activities focusing on modelling CPS are typically based on national activ-ities and generally lack a concerted approach at European level. A dedicated interdisci-plinary and inter-institutional platform for scientific information exchange, consensusbuilding, and model improvement is thus required. COST provides the best availablemechanism for broad European networking and capability-building. A COST Action isthe most appropriate framework since only in a non-competitive, interdisciplinary en-vironment it will be possible to identify and verbalize the weaknesses and uncertaintiesrelated to CPS modelling approaches, to develop common strategies for improving the

Page 44: CISL - Core Insurance Service Layer

effectiveness of such methods, techniques and tools and to develop and broaden theavailable research expertise.

The COST Action MPM4CPS aims to involve, support and harmonize the variousexisting national activities around CPS modelling. One innovative aspect of MPM4CPSis the effort of bringing together scientists and experts in Mechatronics, Smart-Cities,CPS, Software Modelling and Engineering, and Multi-Paradigm Modelling, in orderto push the development and implementation of state-of-the-art scientifically justifiedmethodologies of CPS modelling in several application domains, such as automotiveand avionics. In order to ensure a direct impact of the scientific output, MPM4CPS ischaracterized by a high level of specialization and is aiming at a well defined target.

3 Project Objectives

The main aim of the MPM4CPS Action is to enhance the quality, visibility and impactof European research and industrial adoption in the trans-disciplinary area of CPS. Thisgoal is pursued by building a network of researchers, educators, industrial practitionersand policy makers in order to establish the foundations and methods of CPS engineer-ing enabled by MPM. This allows coordinating and shaping the efforts on research,education and application in this emerging research field.

The objectives of MPM4CPS are the following:– Develop research-based guidelines for evaluating and characterizing CPS.– Evaluate current software engineers’ practice and system engineers’ methods to

identify best practices as well as gaps and opportunities for unification.– Develop hypotheses based on results of national research and development.– Develop benchmark experiments in representative application domains of MPM4CPS.– Develop and apply the MPM approach for combinations of different models, mod-

elling languages, simulation and verification tools and assert their applicability inindustry.

– Evaluate the interdisciplinary know-how required from a software/system’s engi-neer in order to develop and maintain such kind of systems at the European scale,and if necessary develop new course materials in order to cope with such needs.

– Disseminate information and results within several areas.

4 Project Organization

The MPM4CPS Action is planned to last four years and is operated with a organiza-tional structure in full accordance with COST guidelines.

The activities within the Action are coordinated by the Management Committee(MC) and organized around five Working Groups (see Section 4.1). Each participatingcountry has up to two representatives on the MC. MC members are nominated by theCOST National Coordinators (CNCs) of the countries they represent. The MC decideson all budget-related questions, devises the general Action strategy and manages the or-ganisation of the Action’s scientific and technological activities. Balance of gender andgeographical representation is aimed for in the MC and in all WGs. Participation byEarly Stage Researchers (ESR – less than 8 years after PhD) is particularly stimulated.

Page 45: CISL - Core Insurance Service Layer

The Core Group (CG) consists of the chair and the vice-chair of the MC and theleaders of each WG. The CG and ultimately the chair have responsibility for ensuringthat the MPM4CPS Action is on schedule and that specified objectives are met.

High priority is given to Short Term Scientific Missions (STSM) to foster personalcontacts between researchers, where possible from diverse communities (academia-industry, inter-discipline). Regular calls for STSM proposals are planned. An STSMEvaluation Committee assesses the impact of the scientific visits and their output, andthe CG decides on budget allocation.

Training Schools are also key to the Action. In such Training Schools, the chal-lenges, concepts, methods, techniques and tools of MPM4CPS are taught. The intendedaudience is PhD students and ESRs, including attendees from industry.

4.1 Working Groups

Four main Working Groups (WG1–WG4) make up the MPM4CPS Action and are incharge of carrying out all activities. Participants are encouraged to be aware of andparticipate in the activities of all WGs, intentionally avoiding a separation and cluster-ing of participants in mutually exclusive groups. In fact, a dedicated Working Group(WG0) bundles cross-WG activities to ensure their cohesion and boost interdisciplinarycollaboration.

WG0: Cross-WG Activities, Showcases. WG0 plays a special role within MPM4CPSby bundling cross-WG activities in order to ensure their cohesion, boost interdisci-plinary collaborations, while avoiding the natural clustering (e.g., the creation of micro-communities per working group) and minimizing fragmentation and duplication of re-search and efforts within the large network formed by MPM4CPS. Exchanges betweenthe WGs is promoted, also by financially supporting inter-WG visits.

Furthermore, WG0 oversees tasks related to dissemination towards end users, in-cluding the design and development of showcases.

WG1: Foundations - Intra- and Inter-Disciplinary Interaction. The objectivesof WG1 are to apply and mostly combine existing modelling techniques (e.g., MPMtechniques, Control Engineering techniques, Hybrid Systems) while dealing with theheterogeneity of CPS, and identifying common formalisms and ontologies used in CPSdevelopment. WG1 is in charge of characterizing/categorizing existing modelling lan-guages of the different disciplines using typical industrial CPS scenarios, and to com-pile, evaluate, possibly complete and document existing modelling tools for CPS mod-elling. Specific tasks of WG1 include:

– Identify existing CPS methodologies and state-of-the-art in CPS modelling anddevelopment.

– Identify CPS tools and formalisms/disciplines that are currently under developmentand favoured for future application.

– Identify the current generic modus-operandi of a typical industrial CPS developer.– Define a standard terminology (i.e., domain ontology) for CPS.

The deliverables of WG1 are based on previous and ongoing research work, and includea state-of-the-art report on current formalisms used in CPS development, containing:1) a structured catalogue of modelling languages and tools; and 2) a glossary of terms tobe used throughout CPS modelling language evaluation, development, and application.

Page 46: CISL - Core Insurance Service Layer

WG2: Techniques. The objective of WG2 is to conceptualize usable and efficientMPM integrated environments for CPS development, while increasing CPS develop-ment productivity (e.g., by means of increased interoperability, and use of visual mod-elling languages) and reducing the complexity of CPS testing, simulation and certifica-tion procedures. A secondary objective of WG2 is to investigate CPS standards that canbe used by Europeans regulators in order to increase performance, security and safetyof industrial CPS in Europe, and worldwide. Specific goals of WG2 are:

– Investigate which kind of MPM methods and tools are currently under development(e.g., in the domains of software engineering, embedded systems, complex controlsystems) and favoured for future application/integration in CPS.

– Help develop tools, standards and best practices that can be virtually integrated ina conceptual MPM environment.

– Demonstrate and evaluate the increase of efficiency of such modelling environ-ments on CPS (i.e., not only in what matters to development speed, but also oncertification speed).

As a consequence, the deliverables of WG2 include: 1) a report of standards and bestpractices in MPM modelling of CPS; 2) a report on state-of-the-art in MPM modellingtools used in different disciplines; 3) a report containing considerations for future MPMmodelling tools; and 4) an efficiency evaluation of MPM modelling tools on CPS (e.g.,versus non-modelling approaches of CPS development and certification, etc.).

WG3: Application Domains. WG3 focuses on the practical constraints in the use ofMPM modelling in two representative and distinct CPS application domains: 1) embed-ded systems, control systems where CPS has emerged from (e.g., automotive, aerospa-tial); and 2) more networked, unanticipated changes (both structure and behaviour) andless of the traditional plant/controller architecture, which may have emergent behaviour(e.g., smart-cities, complex traffic management). The specific needs of the industry inthese domains have to be taken into account in order to successfully implement thescientific improvements gained by the MPM4CPS Action. WG3 works together withindustrial partners to ensure a bilateral feedback between the scientific and industrialCPS communities. The main tasks covered in WG3 are the following:

– Define benchmark case studies.– Assess the current industrial state of CPS and CPS modelling at a national level.– Collect the requests and requirements of each application domain, and rewrite them

from a CPS perspective.– Assess the suitability of the different application domain models.– Compile recommendations on the proper use of different models, formalisms and

methodologies and the reliable assimilation of current application domain modelsin the perspective of CPS modelling.

The deliverables of WG3 are: 1) a documentation of recommended procedures for theuse of CPS models in the context of several application domains; 2) information onwhich type of model(s) or approach(es) is/are to be used for which type of scenario;3) practical guidelines for the optimal use of CPS models or MPM modelling ap-proaches;4) a report on the current state of the art of CPS and CPS modelling at anational level.

Page 47: CISL - Core Insurance Service Layer

WG4: CPS Education and Dissemination. WG4 focuses on the crystallization ofMPM4CPS contents into a suitable format for dissemination and educational purposes.The specific tasks covered in WG4 are:

– Identify the adequate profile(s) of CPS experts, i.e., minimum required knowledgesuch as formalisms and modelling techniques.

– Identify existing courses in the realm of CPS and MPM4CPS in Europe, and theneed for new courses on topics relevant to CPS not yet covered by universities.

– Lay the foundations for a European Master/PhD program in MPM4CPS involvingseveral European leading universities and set up the respective discipline roadmap.

– Promote literature on the topic, and define course materials.– Promote thematic Summer Schools on MPM4CPS for researchers.– Make young students (future researchers and practitioners) aware of and enthusias-

tic about the topic of CPS in events such as a “CPS Hacker School”.

4.2 Networking Within MPM4CPS

The following instruments are employed by MPM4CPS to pursue its objectives:– Regular coordination meetings (at least two per year) putting particular emphasis

on technical discussions and presentations, and inviting representatives from EUprojects and external experts to participate in the technical discussions.

– A series of yearly workshops and symposia, inviting keynote speakers, lecturerson software modelling and MPM, as well as CPS experts from both academia andindustry. These events will widen the information input and foster the immediatedissemination of results produced by MPM4CPS.

– A series of annual reports surveying the state-of-the-art on MPM for CPS and re-porting case studies on the adoption of CPS technology in real-world applications.

– Yearly training school(s) for young researchers.– Short Term Scientific Missions (STSM) for junior and senior participants.– A website (http://www.mpm4cps.eu) for information exchange between the

members of the Action and to disseminate results.– Internally, a project management portal with a set of thematic discussion forums

and mailing lists to foster collaboration between members.

4.3 Participation

COST Actions are by nature inclusive and actively encourage open participation. Wewelcome new collaborators wishing to participate in the project and contribute to ourgoals. If you want to get involved in the project or to be informed about future eventsand new deliverables, please visit http://mpm4cps.eu/about/take_action.

5 Project Outcomes

During the first year and a half most efforts have been focused on the exchange of infor-mation among members, the identification of the main challenges, and the start of some

Page 48: CISL - Core Insurance Service Layer

initial tasks in every working group. The basic management and project infrastructureare already in place (WG0). WG1 is actively working on a common ontology for CPS.WG2 currently focuses on tools and processes for co-simulation. WG3 collects a setof standard practices in industry and defines target application domains. Finally, WG4has set up the web portal and is preparing course material on MPM and CPS. Concretedeliverables for all these activities are planned by October 2016.

WG and MC Meetings are being held as planned, trying to collocate either withmodeling or with CPS events (such as the CPSweek, for instance). A Young ResearcherWorkshop (in Twente, The Netherlands) and Training School (in Tallinn, Estonia) havetaken place, and new ones are expected soon, together with new calls for STSM. Regis-ter at http://mpm4cps.eu/about/take_action to receive information aboutforthcoming events and calls.

Apart from the outcomes of the individual WGs discussed above, in the last year ofthe action a summarizing report will be finalized, peer-reviewed and published.

6 Exploitation Approach and Expected Impact

The potential impact of MPM4CPS can be characterized as follows:– Formation of a dedicated trans-disciplinary, cross-national pool for information ex-

change intended to last far beyond the lifetime of the MPM4CPS Action.– Increased quality and level of inter-disciplinarity of MPM for CPS research.– Reducing fragmentation of research through the definition of a common research

agenda on MPM for CPS, and by bringing together experts from both research andindustry (MPM4CPS community building).

– Promoting MPM and CPS education by defining the MPM4CPS discipline, whileidentifying the required profile for CPS expertise, and the core of topics, compe-tencies and specialities in MPM4CPS education.

– Synergy between industrial partners from different application domains aroundCPS (expected economical benefits for the European region and leadership estab-lishment of the European institutions in the MPM4CPS area).

– Enhanced competitiveness of European ICT industry by: 1) fostering the adoptionof the MPM4CPS practices and methodologies, capable of boosting the productiv-ity of the development process of existing and new complex application domains,and 2) creating new markets for CPS tooling.

7 Barriers and Obstacles, and Expected Marketing Value

The number, heterogeneity and different backgrounds of the participants can be con-sidered as strong points, but also introduces significant challenges. Coordination andsynchronization of efforts and resources are critical tasks for this Action.

The lack of maturity of some of the methods and tools currently used in some of thedisciplines covered by the Action may represent a real impediment for the industrialadoption of the MPM4CPS approach. Being an COST Action we can identify what ismissing or immature. We expect (EU) projects spinning off from this Action to addressthe limitations and issues encountered, in order to facilitate the full industrial adoption

Page 49: CISL - Core Insurance Service Layer

of MPM4CPS practices and tools. Moreover, information about state-of-the-art embed-ded systems, mechatronics for avionics, mechatronics for automotive, etc., are alreadyexchanged among European countries, but mostly via independent application-specificindustrial standards. There is a clear need to bring different solutions from differenttechnology and application domains together around CPS.

This action aims at creating the conditions necessary for promoting the sharing ofresources, by integrating, under a common umbrella (i.e., in a consistent and system-atic way with a common terminology), the knowledge and experiments across severalresearch projects around Europe (and beyond). In addition, it provides a unique oppor-tunity to establish international cooperation, and to exchange materials (data, models,insights) and compare results. Finally, this Action is expected to provide input to Euro-pean policy with respect to regulations of the methodologies and procedures to developand certify this kind of systems, combining national and international legislation. Hereis a unique opportunity to determine appropriate ways of dealing with CPS in differentindustrial environments.

8 References to Related Work and Related Projects

The MPM4CPS Action focuses on MPM for CPS, and these aspects combined arenot covered by other COST Actions or EU-projects. As the Action necessarily has toinclude many aspects of CPS (e.g., mechatronics in several application domains), thereare links with other research programmes as indicated in the following:a) Links and complementarity with other COST Actions

– IC0901 - Rich-Model Toolkit - An Infrastructure for Reliable Computer– IC285 - Modelling and Simulation Tools for Research in Emerging Multiser-

vice Telecommunicationsb) Links with other EU research programmes

– Cyber-Physical Systems European Roadmap and Strategy (CyPhERS).– CPS Action Line “Cyber Physical Systems” of the EIT ICT KIC.– Industrial Framework for Embedded Systems Tools (iFEST).– Combined Model-based Analysis and Testing of Embedded Systems (MBAT).– Integrated Tool Chain for Model-based Design of CPS (INTO-CPS).– Trans-Atlantic Modelling and Simulation for Cyber-Physical Systems (TAMS4CPS).

Acknowledgements. COST IC 1404 MPM4CPS is supported by the EU FrameworkProgramme Horizon 2020.

References

1. Amaral, V., Hardebolle, C., Vangheluwe, H., Lengyel, L., Bunus, P.: Recent advances in multi-paradigm modeling. ECEASST 50 (2011)

2. Mosterman, P.J., Vangheluwe, H.: Guest editorial: Special issue on computer automated multi-paradigm modeling. ACM Trans. Model. Comput. Simul. 12(4), 249–255 (Oct 2002)

3. Rajkumar, R.R., Lee, I., Sha, L., Stankovic, J.: Cyber-Physical Systems: The Next ComputingRevolution. In: Proc. of DAC’10. pp. 731–736. ACM (2010)

4. Vangheluwe, H., de Lara, J., Mosterman, P.J.: An introduction to multi-paradigm modellingand simulation. In: Proceedings of the AIS’2002 Conference (AI, Simulation and Planning inHigh Autonomy Systems). pp. 9 – 20 (April 2002), Lisboa, Portugal.

Page 50: CISL - Core Insurance Service Layer

Interfacing Real-Time Systems for AdvancedCo-Simulation – The ACOSAR Approach

Martin Krammer, Nadja Marko, and Martin Benedikt

VIRTUAL VEHICLE Research Center, Inffeldgasse 21a, 8010 Graz, Austria{firstname.secondname}@v2c2.at

http://www.v2c2.at

Abstract. Virtual system development is getting more and more impor-tant in a plenitude of industrial domains to reduce development times,stranded costs and time-to-market. Co-simulation is a particularly promis-ing approach for modular and interoperable development. In practicethe integration and coupling of real-time systems (especially systems ofdistributed hardware-in-the-loop systems and simulations) still requiresenormous efforts. The aim of the ACOSAR project is to develop botha non-proprietary Advanced Co-simulation Interface (ACI) for real-timesystem integration and an according integration methodology. These pro-posals shall act as a substantial contribution to international standard-ization as the Functional Mock-up Interface (FMI) standard laid thefoundations for simulations of physical systems. The results of ACOSARwill lead to a modular, considerably more flexible, as well as shortersystem development process for numerous industrial domains and willenable the establishment of new business models.

Keywords: co-simulation, simulation, real-time, ACI, FMI, integration

1 Introduction

With this paper the ACOSAR project is introduced. ACOSAR is the abbrevia-tion for “Advanced Co-Simulation Open System Architecture". It is an ITEA 3framework project. ITEA is the EUREKA cluster programme supporting inno-vative, industry-driven, pre-competitive research and development projects inthe area of software-intensive systems and services (SiSS). SiSS are a key driverof innovation in Europe’s most competitive industries, such as automotive, com-munications, healthcare and aerospace1. ACOSAR is the first project of its kindbeing proposed and approved in Austria. It is led by VIRTUAL VEHICLE, arenowned automotive research center located in Graz, Austria. As of April 2016,the project is in the midst of its first year. Table 1 shows the key project factsat a glance.

ACOSAR responds to a strong market request in a plenitude of industrialdomains: a consistent, seamless (virtual) system development and validation. Inorder to achieve this, ACOSAR uses a modular co-simulation approach, sup-porting flexible system development by its modular characteristics, to integrate1 http://www.itea3.org

Page 51: CISL - Core Insurance Service Layer

Name ACOSAR: Advanced Co-Simulation Open System ArchitectureFramework ITEA 3Funding National funding agencies, total budget 7.9 million eConsortium 15 partners from 3 countries (Austria, France, Germany)Structure 3 OEMs (Porsche, Renault, and Volkswagen)

1 supplier of automotive systems, components (Bosch)4 industry providers (AVL, AVL-AST, ETAS and dSPACE)2 simulation tool vendors (Siemens PLM Software, ITI)3 SMEs (MEDS, TWT, and ITI)1 research center (VIRTUAL VEHICLE)3 academic (Leibniz University Hannover, RWTH Aachen, and IlmenauUniversity of Technology)

Leader VIRTUAL VEHICLE Research Center, AustriaPeriod September 2015 – August 2018Website http://www.acosar.eu

Table 1. The ACOSAR project at a glance.

domain-specific subsystems. In development stages, where real-time (RT) sys-tems have to be integrated into simulation environments, huge configurationeffort is still necessary due to complex system topologies, large numbers of sig-nals, and numerous different parameters of algorithms for signal processing.

© VIRTUAL VEHICLEAugust 2014 / Benedikt ACOSAR - Project proposal 3

Co-simulation Environment

SimulationEnvironment FMU

Drivetrain

SimulationEnvironment

Li-Ion Battery

Cooling

FMU

Ordinary User PC or Computing Cluster

(Co-) Simulation Environment

ACI Communication Layer

Functional Framework

(e.g. enginetestbench)

Communication Systems

Smart Functions(e.g. adaptive coupling)

RT System

WiredCommunication

(e.g. CAN)

WirelessCommunication(e.g. BlueTooth®)

InterprocessCommunication(e.g. shared mem.)

Proprietary Interface Functional Mockup Interface (FMI) Advanced Co-Simulation Interface

Fig. 1. The main idea behind ACI is strongly related to FMI, but ACI relates to acompletely different domain of application. In particular, FMI addresses integrationof simulation models (only) within the non-RT or the RT domain. In contrast, themajor focus of ACI is on integration of RT-systems into simulation environments byinterconnecting the RT with non-RT or RT domains.

2 Goals and Objectives

To enable effective and efficient RT-system integration, ACOSAR will provideinnovations on different levels. First, ACOSAR focuses on the specification of a

Page 52: CISL - Core Insurance Service Layer

non-proprietary open RT-system interface, a so-called Advanced Co-simulationInterface (ACI) for sharing relevant information for efficient and safe operationof RT-systems, e.g. test beds. A communication architecture (including protocol)will be defined, which will be independent of the used communication systems. Afunctional framework for coupling strategies, highly efficient data transmission,and support of semantic data processing will supplement this. These aspects areillustrated in Figure 1. Furthermore, a comprehensive methodology for seamlessintegration of RT-systems during verification, test and validation phases withinthe development cycles of the classical V-process model will be defined. Thismethodology will support already existing tool chains, model-based systems en-gineering approaches, and methods for easy adaption of simulation tools fromearly development phases to late ones. The latter is supported by a continuoustransfer of knowledge as progress in product development is made.

The open ACOSAR ACI not only will make it possible to extend cloud-based simulation applications towards the RT domain, but also to select andapply best-in-class RT-systems to compose a dedicated optimum overall systemfor specific present problems with reduced error proneness (e.g. interconnectionof distributed HiL test beds for specific engineering purposes). Besides spread-ing such kind of solutions for the benefit of other domains, this also will help toimprove the social acceptance of new technologies, e.g. autonomous driving. Fur-thermore, research on smart functionality including adaptive coupling strategieswill be stimulated.

The major results of ACOSAR will be freely available.Thus, ACOSAR con-tributes to interoperability and open access. It also supports competition andwill lead to a modular, more flexible, as well as much shorter system developmentprocess and will enable new business models.

The transfer of project results into standardization is the key goal of ACOSAR.Therefore, partners from relevant standardization committees (e.g. FMI/ModelicaAssociation, ASAM) are actively involved to jointly create solutions and exten-sions to existing standards. To further bridge the gap between the automotivedomain and other domains, leading partners from e.g. aviation and rail will beinvited to ACOSAR as associated members. Not at least, ACOSAR’s innova-tions will enable small and medium-sized enterprises (SME) and suppliers fromdifferent domains (software tools, HiL systems, test beds,. . . ) getting access tomajor industries, resulting in more competitive markets in the long term.

3 Related Work

The ACOSAR consortium reviewed numerous research projects, scientific pa-pers and industry standards with respect to all relevant fields. This includestopics like modeling and simulation of continuous, discrete and hybrid systems,co-simulation and coupling mechanisms, communication systems, real-time ap-plications as well as systems and safety engineering. The majority of these liter-ature review results will be published in deliverable D1.1.

One of the most relevant standards considered for investigation is the func-tional mock-up interface (FMI) standard [6]. Version two was released in 2014.

Page 53: CISL - Core Insurance Service Layer

FMI is a tool-independent standard to support both model exchange and co-simulation of dynamic models2. Its main goal is to improve the exchange ofsimulation models between suppliers and OEMs within the automotive industry.

Recent relevant publications include [8] on FMI-based distributed multi-simulation, or [3] on requirements for hybrid co-simulation standards. Regardingissues of coupling and practical applications of co-simulation, [9,1,2,12] weretaken into account. Publications covering industrial use cases are describedin [10,7,5,4].

Some of the most relevant research projects included AGeSys, ASTERICS,AVANTI, INTO-CPS, MODELISAR, OPENPROD, ACORTA 1 and ACORTA 2,Transformers and VeTeSS.

4 The ACOSAR Approach

4.1 Project Overview and Structure

An organizational overview is given in Figure 2. Work package (WP) 1 is named"Open System Architecture Requirements". It builds the foundation for all sub-sequent WPs and unifies the stakeholder’s views through specification of re-quirements (for this approach see Section 4.4). WP 2 is titled "Real-time systemintegration methodology". It focuses on system level activities, including sys-tem modelling and configuration approaches, as well as tool integration issues.WP 3 deals with "Simulation tool interfaces", and is targeted towards the needsof software tool vendors. WP 4 specifies the "Real-time system interface", andtakes hardware and testing systems into account. WP 5 focuses on the "Commu-nication protocol", which is used to interconnect multiple systems via commonlyused communication media. Finally, WP 6 is intended to condense the resultsof WPs 3-5 and master the task of creating a first version of the ACI specifi-cation. Industrial and scientific demonstrator applications are planned, set upand assessed within WP 7 named "Application use-cases and assessment". Dis-semination, standardization, and exploitation activities take place within WP 8,throughout the entire run-time of the project. WP 9 is concerned with overallproject management activities.

4.2 Expected Outcomes of Workpackages and Deliverables

The outcome of WP 1 are sets of requirements (D1.1: Open system architec-ture requirements) targeting different application levels and levels of abstraction.They build on top of current standards, state-of-the-art technology, and best in-dustry practices. The project’s 9 use cases of WP 7 support these steps. Moreon this in Section 4.4. The use cases will be assessed in WP 7’s deliverable D7.1:Documentation of use cases, tests, configurations, and measurement results, todemonstrate the impact of ACOSAR’s developments.

WP 2 defines the understanding of system simulation in the project, and as-sesses properties of interfaces and subsystems. If these can be described properly,2 http://www.fmi-standard.org

Page 54: CISL - Core Insurance Service Layer

© VIRTUAL VEHICLE

ACOSAR

ACOSAR - HR/FRA Consortium 2

WP 9 - Project Management

WP 1 – Open System Architecture Requirements

Interfacing Requirements System architecture Testing procedure

Current standardsFMI, ASAM XiL-API, XCP, etc.

Funded associated projectsModelisar, ACoRTA, etc.

Associated member groupsAviation, Rail, Maritime, etc.

WP 2 – RT-System Integration Methodology

MBSE for RT-System integration

Co-simulation system configuration

Tool-chain integration

WP 6 – Advanced co-simulation interface (ACI)

Framework for coupling strategies

Specification for the overall ACI

WP 6 – Application Use-Cases and Assessment

Industrial applications

Scientific applications

Exploitation plans and measures

(2016-2018)

Dissemination tools

(2015-2017)

Standardizationactions

(2017-2019)

WP 8 – Dissemination& Exploitation

WP 3 – Simulation tool interface1. Interface specification2. Prototype implementations3. Initial test and evaluation

WP 4 – RT-System interface1. Interface specification2. Prototype implementations3. Initial test and evaluation

WP 5 – Communication protocol 1. Abstraction of bus system2. Prototype implementations3. Initial test and evaluation

16.10.2014 / Benedikt

Commonly usedcommunication

media

ACI

Fig. 2. ACOSAR Project Structure.

an investigation of means for system configuration and tool chain integration isthe next step. These results are consolidated in D2.1: Handbook on RT-systemintegration methodology, which is jointly developed with WPs 3-5. WP 3 willdeliver D3.1: Specification of simulation tool interface, which aims at continuousand discrete simulation as well as real time constraints for co-simulation. Themain output of WP 4 is D4.1: Specification of RT-system interface. It targetsreal-time-systems and includes related possible test specifications. WP 5’s maindeliverable D5.1: Specification of communication architecture and communica-tion protocol acts as a connector between WPs 2,3 and 4, from a communica-tions point of view. The first version of the ACI specification, application guideand test suite will be published in the project’s core deliverables D6.1, D6.2, andD6.3.

Dissemination and exploitation plans are made in context of WP 8’s D8.2and D8.3, respectively. The executive board (project and WP leaders) deter-mines strategies to ensure the quality of deliverables, review and assessmentcriteria, as well as effective risk management throughout the project. This willbe documented in D9.1: Quality assurance and risk management plan.

4.3 Use Cases and Assessment

The ACOSAR partners contribute a total of 9 use cases to the project. On onehand, they are used as a starting point for the requirements engineering process.On the other hand, they help to assess the effectiveness of the ACI and analyzethe impact of related process modifications. Due to the large number of usecases and their high variability within their configurations, a summary is given

Page 55: CISL - Core Insurance Service Layer

as follows. Popular scenarios include the coupling of offline simulation platformswith online real-time systems. Typical examples for real-time-systems are testbeds for engines or vehicle brake dynamometers. Related to that, the exchangeof single simulation models or software components with their real-time-systemcounterparts is a beneficial approach for X-in-the-loop testing. In this context,electronic control units (ECU) or virtual ECUs (vECU) are candidate platforms.One use case also includes a driving simulator for human interaction evaluation.

Different analyses were conducted on these use cases. Elicited technical chal-lenges include e.g. the exchange of simulation data between offline and onlinesimulation systems, or the integration of multiple ACI interfaces per device orplatform.

4.4 Requirement Engineering for ACI Specification

In WP 1 requirements for the ACI are collected and managed as they serve asa basis for subsequent work packages. In order to capture requirements of theentire project in a structured way, a project specific requirements engineeringprocess has been created. It contains the artifacts shown in Figure 3.

Project goals Use Cases

ICT methodsCore requirements

Technical requirements

Technical scenarios

n

m

n

n

m

n

1n

m

n

m

WP Level

Project Level

m

Fig. 3. ACOSAR requirement process artifacts

Project Goals represent the main objectives that are described in the projectproposal. Together with ACOSAR’s industrial Use Cases they build the basisfor the specification of ACI requirements. Use Cases (from WP 7) describe RTco-simulation scenarios for which ACOSAR partners want to achieve a solution.They are going to be demonstrated at the end of the project.

ICT methods describe functions of co-simulation scenarios on an abstractlevel of detail and mainly from a user’s point of view. The methods should on theone hand help to get a common understanding about the ACI functions withinthe project team and on the other hand be a basis for writing requirementsand Technical scenarios. After the definition of ICT methods, partner relatedUse Cases are described in more detail by specifying Technical scenarios, whichrepresent detailed activities of the co-simulation scenario of the Use Case. Table 2shows the used template for specification of Technical scenarios, next to an

Page 56: CISL - Core Insurance Service Layer

example specification. As Technical scenarios are based on the abstract scenariofrom the ICT method, the template contains (in addition to the concrete UseCase) specific steps of the abstract scenario for traceability reasons.

ID UseCase3_SysInt03Method name Define timing requirementsRationale Define timing requirements for integration of RT systemsGoal Define RT requirements for coupling signalsPreconditions Co-simulation units and coupling signals are definedPostconditions Timing requirements are definedAbstract scenario 1. Define communication step size per coupling signal

2. Define tolerable violation of timing requirements3. Define timing constraints

NotesTechnical scenario 1a. Coupling signal speed: 10 ms sample time

1b. Coupling signal control action: 10 ms sample time2a. Coupling signal speed: 10 ms delay tolerable2b. Coupling signal control action: no delay tolerable3a. Controller model executes 10 times faster than wall-clock-time

Table 2. Technical scenario

Based on ICT methods and Technical scenarios, the Core and Technical re-quirements are derived. Core requirements are project requirements for the ACIand represent the main functionality. They are derived from Project goals andICT methods. In contrast to Core requirements, Technical requirements are workpackage related and represent a detailed, technical specification.

For writing requirements, EARS boilerplates [11] are used. The predefinedsyntax of boilerplate based requirements helps writing good quality requirements(uniform and comprehensible). The requirements serve as basis for future refer-ence implementations as well as for the ACI specification.

5 Exploitation & Innovation

The major innovations of ACOSAR will influence different economic, industrialand scientific areas. Three potential fields of innovation can be identified.

1. ACOSAR features technological innovations by advancing solutions for inter-operability problems. The considered communication architecture is basedon the ACI and allows the implementation of end user key knowledge. Thetechnological break-through results from dramatically shortened setup timefor verification and validation activities within the generic V-diagram.

2. ACOSAR enhances the overall product development process. By using theACI, the integration of real-time systems relies on information gathered ear-lier during system design and specification phases as well as during the sys-

Page 57: CISL - Core Insurance Service Layer

tem simulation phase. Therefore, a beneficial transfer of knowledge is intro-duced into the development process.

3. Using ACIs functional framework, users are able to implement smart func-tionalities in their real-time applications. For instance, crucial problems likecommunication latency of cyber-physical systems (CPS) can be addressedefficiently. This facilitates robust and accurate system development in a spa-tial and temporal distributed development environment.

6 Outlook

In this paper we presented the ACOSAR project. Its primary goal is the develop-ment of the advanced co-simulation interface (ACI). Progress towards this highaim is already made, and the most significant results including the describedmaterials will be available to the public in Summer 2018.

References1. Andersson, A., Fritzson, P.: Models for Distributed Real-Time Simulation in a Ve-

hicle Co-Simulator Setup. 5th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools pp. 131–139 (2013), http://www.ep.liu.se/ecp/084/016/ecp13084016.pdf

2. Benedikt, M., Hofer, A.: Guidelines for the Application of a Coupling Methodfor Non-iterative Co-simulation. 2013 8th EUROSIM Congress on Modelling andSimulation pp. 244–249 (2013), http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7004951

3. Broman, D., Greenberg, L., Lee, E.A., Masin, M., Tripakis, S., Wetter, M.: Re-quirements for hybrid cosimulation standards. Proceedings of the 18th Interna-tional Conference on Hybrid Systems Computation and Control - HSCC ’15 pp.179–188 (2015), http://dl.acm.org/citation.cfm?doid=2728606.2728629

4. Brückner, Swynnerton: Busbasiertes Architekturkonzept für Hardware-in-the-Loop-Prüfstände. ATZ elektronik pp. 52–56 (04 2014)

5. Faure, C., Ben Gaid, M., Pernet, N., Fremovici, M., Font, G., Corde, G.: Meth-ods for real-time simulation of Cyber-Physical Systems: application to automotivedomain. IWCMC 2011 - 7th International Wireless Communications and MobileComputing Conference pp. 1105–1110 (2011)

6. Functional Mock-up Interface for Model Exchange and Co-Simulation, Version 2.0(2014)

7. Friedrich, M.: Parallel Co-Simulation for Mechatronic Systems. Ph.D. thesis, Tech-nische Universität München (2012)

8. Galtier, V., Plessis, G., Renardi, L.: FMI-Based Distributed Multi-Simulation withDACCOSIM. Spring Simulation Multi-Conference pp. 804–811 (2015)

9. Geimer, M., Krüger, T., Linsel, P.: Co-Simulation: gekoppelte Simulation oderSimulatorkopplung. O+P Zeitschrift für Fluidtechnik pp. 4–8 (2006)

10. Hommel, M.: Parallelisierte Simulationsprozesse für virtuelles Prototyping in derAutomobilindustrie. Ph.D. thesis, Technische Universität Braunschweig (2006)

11. Mavin, A., Wilkinson, P.: Big Ears (The Return of "Easy Approach to Require-ments Engineering"). In: Proceedings of the 18nd IEEE International RequirementsEngineering Conference. pp. 277–282 (2010)

12. Völker, L.: Untersuchung des Kommunikationsintervalls bei der gekoppelten Simu-lation. Karlsruher Institut für Technologie (KIT), KIT Scientific Publishing (2010)