UvA-DARE (Digital Academic Repository) Collaborative networks … · Freixo Guedes Osório, A. L. (2020). Collaborative networks as open Informatics System of Systems (ISoS). General

UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl)

UvA-DARE (Digital Academic Repository)

Collaborative networks as open Informatics System of Systems (ISoS)

Freixo Guedes Osório, A.L.

Publication date2020Document VersionFinal published versionLicenseOther

Link to publication

Citation for published version (APA):Freixo Guedes Osório, A. L. (2020). Collaborative networks as open Informatics System ofSystems (ISoS).

General rightsIt is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s)and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an opencontent license (like Creative Commons).

Disclaimer/Complaints regulationsIf you believe that digital publication of certain material infringes any of your rights or (privacy) interests, pleaselet the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the materialinaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letterto: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. Youwill be contacted as soon as possible.

Download date:19 Jul 2021

https://dare.uva.nl/personal/pure/en/publications/collaborative-networks-as-open-informatics-system-of-systems-isos(233a4628-282e-4650-9ffb-b3d7b3187e2a).html

Collaborative Networks as Open

Informatics System of Systems

(ISoS)

António Luís Freixo Guedes Osório

Collaborative Networks as Open Informatics System of Systems (ISoS)

ACADEMISCH PROEFSCHRIFT

ter verkrijging van de graad van doctor

aan de Universiteit van Amsterdam

op gezag van de Rector Magnificus

prof. dr. ir. K.I.J. Maex

ten overstaan van een door het College voor Promoties ingestelde commissie,

in het openbaar te verdedigen

op vrijdag 18 december 2020, te 16.00 uur

door António Luís Freixo Guedes Osório

geboren te Ferreiros de Avões, Lamego

iii

Promotiecommissie

Promotor: prof. dr. H. Afsarmanesh Universiteit van Amsterdam

Copromotor: dr. A.S.Z. Belloum Universiteit van Amsterdam

Overige Leden: prof. dr. ir. C.T.A.M. de Laat Universiteit van Amsterdam

prof. dr. T.M. van Engers Universiteit van Amsterdam

prof. dr. R.V. van Nieuwpoort Universiteit van Amsterdam

prof. dr. L.M. Camarinha-Matos Universidade Nova de Lisboa

dr. P. Grosso Universiteit van Amsterdam

dr. Z. Zhao Universiteit van Amsterdam

Faculteit der Natuurwetenschappen, Wiskunde en Informatica

iv

This research was carried out at Instituto Superior de Engenharia de Lisboa,

ISEL (Engineering Institute of the Polytechnic Institute of Lisbon), research group

GIATSI, and the research association POLITEC&ID in a partnership with the

University of Amsterdam, Federated Collaborative Networks Group (FCN) and

Universidade Nova de Lisboa (New University of Lisbon)/UNINOVA Institute. The

research for this doctoral thesis received financial assistance from grants of

Brisa/BIT/A-to-Be, Galp, BP Portugal, ANSR, and APL.

Copyright © 2020 by Luís Osório

Cover design by Rita Máximo and Matilde Reis

Printed and bound by GRÁFICA99

ISBN: 978-989-33-1118-9

v

To Paula

With Her Love and Strength

and

Maria, Luísa, and João

vii

Contents

1 Introduction ............................................................................................. 1

1.1 Problem Area Motivation Cases ........................................................ 4

1.1.1 The Electronic Toll Collection (ETC) case ................................... 4

1.1.2 The HORUS case .......................................................................... 5

1.1.3 The SINCRO case ......................................................................... 6

1.1.4 The MIELE case ............................................................................ 7

1.2 Problem Area Challenges .................................................................. 8

1.2.1 Vast heterogeneity ......................................................................... 9

1.2.2 Distribution .................................................................................. 11

1.2.3 Autonomy .................................................................................... 11

1.3 Research Methodology .................................................................... 14

1.4 Research Questions ......................................................................... 17

1.5 Design Challenges for Open ISoS ................................................... 20

1.6 ISoS and Collaborative Networks ................................................... 22

1.7 Thesis Structure ............................................................................... 25

2 Related Research - Developing Open Informatics System of Systems

27

2.1 Informatics Systems Specifics - Isystems ....................................... 29

2.1.1 Gap between informatics engineering expertise and domain

knowledge 29

2.1.2 Informatics system engineering ................................................... 30

2.2 Open Modularity Frameworks ........................................................ 32

2.2.1 SOA paradigm for modularity ..................................................... 33

Contents

viii

2.3 Web Technology Facilitators .......................................................... 34

2.3.1 Interface languages ..................................................................... 34

2.4 Open Reference Architectures and Substitutability ........................ 36

2.4.1 Vendor lock-in challenges .......................................................... 37

2.4.2 Reference architectures ............................................................... 37

2.4.3 Substitutability support ............................................................... 39

2.5 Cyber-physical Systems and Microservices ................................... 41

2.6 Integration of Enterprise Informatics Systems ............................... 45

2.6.1 Integration strategies ................................................................... 45

2.6.2 Modularity abstraction strategies ................................................ 47

2.7 Integration of Isystem in Collaborative Networks .......................... 49

2.8 Summary ......................................................................................... 52

3 Interoperability Through Services ...................................................... 55

3.1 Electronic Toll Collection (ETC) Case ........................................... 57

3.2 Analysis of ETC system ................................................................. 60

3.3 Specification of ITSIBus Model ..................................................... 63

3.4 Proof of Concept Prototype ............................................................ 68

3.5 Migration Project Application at Brisa Industry ............................. 73

3.6 Summary ......................................................................................... 74

4 The Isystem of systems (ISoS) Framework ........................................ 77

4.1 From ITSIBus to CES ..................................................................... 79

4.2 ISoS Modeling Elements – CES and Isystem ................................. 81

4.2.1 Cooperation Enabled System (CES) ........................................... 83

4.2.2 Isystem of systems (ISoS) .......................................................... 87

4.3 Substitutability of CES and Isystem ............................................... 95

4.3.1 Substitutability principle at CES level ........................................ 96

4.3.2 Substitutability principle at Isystem level ................................... 97

4.4 Process Modeling Paradigms and Standards .................................. 99

4.4.1 Systems modeling paradigms ................................................... 100

Contents

ix

4.4.2 Agile bind of process activities to Isystem and CES components

101

4.5 Open ETC Case ............................................................................. 102

4.6 Strategy for an Open ISoS Framework ......................................... 103

4.6.1 Substitutability principles .......................................................... 104

4.6.2 Conformity certification process ............................................... 106

4.7 Summary ....................................................................................... 107

5 ECoNet CNO Infrastructure and CEDE Development Platform ... 109

5.1 Collaborative Networks and Informatics Systems Landscape ...... 111

5.2 The enterprise collaborative network ............................................ 114

5.2.1 Enterprise collaboration manager .............................................. 116

5.2.2 Virtual collaboration context ..................................................... 122

5.3 Isystem in Collaborative Networks Context .................................. 124

5.3.1 ECoM as Isystem of ISoS framework ....................................... 128

5.4 Development Strategy and Validation Methodology .................... 130

5.4.1 The Collaborative enterprise development environment (CEDE)

131

5.5 Summary ....................................................................................... 139

6 Research and Development Results Validation ................................ 141

6.1 Multi-Supplier Induced Value ....................................................... 143

6.2 Validation Cases ............................................................................ 145

6.2.1 Implementation of ETC case at Brisa concessionaire ............... 146

6.2.2 Implementation of petrol distribution forecourt case HORUS

Isystem 149

6.2.3 Implementation case of National Speed Enforcement Network

(SINCRO) 156

6.2.4 Implementation of Logistics and transport MIELE case ........... 163

6.3 Model and Methodology for Large Complex Tenders .................. 166

6.4 Open Innovation and Value Creation ............................................ 169

6.5 Summary ....................................................................................... 170

Contents

x

7 Conclusions and Further Research Challenges ............................... 173

7.1 Summing up .................................................................................. 173

7.2 Contributions to Sustainable Integrated Isystems Landscapes ..... 175

7.2.1 Intra-organization and collaborative networks dimension ........ 176

7.3 Future Research Work .................................................................. 180

7.3.1 Addressing the gap between technology and processes/application

domains 180

7.3.2 Semantics standardization efforts ............................................. 182

7.3.3 Dependability of systems .......................................................... 183

7.3.4 Security challenges and risks .................................................... 185

Bibliography ................................................................................................ 187

Publications List .......................................................................................... 207

Code.............................................................................................................. 211

Acknowledgments ....................................................................................... 213

Abstract ........................................................................................................ 217

Samenvatting ............................................................................................... 221

xi

List of Figures

Figure 1 – Current architecture of intra- and inter-organizations’ ITsystems

integration ................................................................................................. 10

Figure 2 - The strategy for challenging ITsystems towards Isystems ..................... 13

Figure 3 – Projection of research in the Design Science Framework; adapted from

[197] .......................................................................................................... 15

Figure 4 – Timeline and research objectives considered in the development of the

ISoS framework ........................................................................................ 16

Figure 5 – The inter-organization IT integration strategy ....................................... 18

Figure 6 – Collaborative Networked Organizations linked by ECoNet Infrastructure

.................................................................................................................. 24

Figure 7 – A Foreseen trend for Intelligent Web Services from [53] and [113] ..... 35

Figure 8 – IT4IT Reference Architecture Levels [141] ........................................... 38

Figure 9 - Evolution from ECS to the Internet of Things, Data, and Services [128]

.................................................................................................................. 42

Figure 10 – Prevailing interactions infrastructure for the fast-emergent

collaborations ............................................................................................ 51

Figure 11 – The monolithic enterprise applications perspective ............................. 61

Figure 12 – Disintegration process of a monolithic application/system ................. 62

Figure 13 – The proposed execution container for the ITSIBus services ............... 65

Figure 14 – Details of the ITSIBus enabled system as a service container ............. 67

Figure 15 – General ITSIBus architecture for a toll application domain ................ 68

Figure 16 – Architecture for the eTOLL prototype ................................................. 69

List of Figures

xii

Figure 17 – A view of the ITSIBus Eclipse-based workbench development

framework ................................................................................................ 71

Figure 18 – The ITSIBus System and Service concepts ......................................... 71

Figure 19 – ITSIBus service specializations for the toll application ...................... 72

Figure 20 – Event data type and specializations for the tolling application domain

.................................................................................................................. 73

Figure 21 – Supporting adapter-based integration of systems provided by different

suppliers ................................................................................................... 80

Figure 22 – The Collaboration Enabled System/Services (CES) SysML model .... 85

Figure 23 - The SysML model of the Generic Modeling Entity (GME) value type

.................................................................................................................. 86

Figure 24 – The SysML model of an Informatics system (Isystem) ...................... 88

Figure 25 – The SysML model of the ISoS Framework......................................... 91

Figure 26 – The organization’s Isystem of systems (ISoS) .................................... 92

Figure 27 – Management of heterogeneous execution environments .................... 93

Figure 28 – The open Electronic Toll Collection Isystem as CESs ........................ 97

Figure 29 - The open ETC as a set of Isystem ........................................................ 98

Figure 30 – An Electronic Toll Collection as an Isystem ..................................... 102

Figure 31 – The SysML model of Isystems and CES standardization elements .. 105

Figure 32 – Organizations manage uncoordinated point-to-point collaborations 113

Figure 33 – The main elements of the ECoNet infrastructure .............................. 115

Figure 34 – The ECoM Context Architecture ...................................................... 116

Figure 35 – The Collaboration Context (CoC) as a specialization of a CES ........ 118

Figure 36 – The Collaboration Contexts ECoNet, ECoMsgExchange, and LSW 120

Figure 37 – The Organization concept modeling an ECoNet node (organization

profile) .................................................................................................... 121

Figure 38 – The Virtual Collaboration Context (VCC) concept .......................... 123

Figure 39 – A snapshot of the ECoMsgExchange ECoNet reference Isystem ..... 123

Figure 40 – The ECoNet as an Isystem of the open ISoS infrastructure .............. 127

List of Figures

xiii

Figure 41 – A global perspective of ECoNet platform under the ISoS model ...... 129

Figure 42– From a closed to an open Isystem ....................................................... 132

Figure 43 – The Model Driven Open Systems strategy ........................................ 133

Figure 44 – A possible CEDE layout involving organization and Cloud ............. 137

Figure 45 – The CEDE unified collaborative development environment ............. 138

Figure 46 – The ISoS contribution to abstracting Specific Technologies

Independence .......................................................................................... 144

Figure 47 – The ITSIBus architecture as adopted by Brisa company ................... 148

Figure 48 – General Architecture of the HORUS Isystem/solution ...................... 151

Figure 49 – Adoption of an ECoNet specialized CoCHORUS Collaboration Context

................................................................................................................ 154

Figure 50 – The exchange of business data through the ECoM Isystem .............. 155

Figure 51 – State of the market before the SINCRO standards ............................. 157

Figure 52 – After SINCRO open specifications (towards standards) ................... 158

Figure 53 – SINCRO general architecture ............................................................ 159

Figure 54 – A detailed view of the SINCRO open interfaces ............................... 160

Figure 55 – A view from the SINCRO conformity verification/certification

workbench ............................................................................................... 162

Figure 56 – The proposed convergence strategy for the existing JUP/PSW ......... 165

Figure 57 – Methodology for the development of complex ISoS ......................... 166

xv

Abbreviations

ANSR National Road Safety Authority

BPMN Business Process Modeling and Notation

CEDE Collaborative Enterprise Development Environment

CES Cooperation Enabled Services (former System)

CN Collaborative Network

CNO Collaborative Networked Organizations

CoC Collaboration Context

DMN Decision Modeling and Notation

DSRC Dedicated Short Communication

ECoM Enterprise Collaboration Manager

ECoNet Enterprise Collaborative Network

ESB Enterprise Service Bus

ETC/EFC Eletronic Toll Collection / Electronic Fee Collection

eTOLL Self-service Tolling Lane

GME Generic Modeling Entity

IMA Integrated Modular Avionics

IoT Internet of Things

ISoS Informatics System of Systems

Isystem Informatics System

ITS Intelligent Transport Systems

ITSIBus Intelligent Transport Systems Interoperability Bus

Abbreviations

xvi

JINI Java Distributed Services Framework

JUP Janela Única Portuária, in English, Port Single Window

LMS Lane Management System/Services

LPR License Plate Recognition

LSW Logistics Single Window

MDEOS Model Driven Engineering Open Systems

MIELE Multimodal Interoperability E-services for Logistics and

Environment sustainability

MIME Multipurpose Internet Mail Extensions

MOBICS Mobility Intelligent Cooperative Systems

OACI Open Adaptive Coupling Infrastructure

PCS Port Community System

PDOSBus Petrol Distribution Open Service Bus

POS Point of Sale

PSW Port Single Window (Janela Única Portuária – JUP, in

Portuguese)

REST Representational State Transfer

RSE/RSU Road Side Equipment/Unit

SIGET Traffic Events Management System

SINCRO National Speed Enforcement Network

SOA Service Oriented Architecture

SoS System of Systems

SysML Systems Modeling Language

VBE Virtual Breeding Environment

VCC Virtual Collaboration Context

VO Virtual Organization

1

Chapter 1

1 Introduction

Building integrated complex information technology systems (ITsystem) or a system

of systems (SoS) based on the growing number of emerging applications has

reopened the traditional and challenging debate of dealing with integration in legacy

enterprise systems and the openness of the overall solution. Throughout this

dissertation, the term “open” will be used to refer to an agnostic technology

landscape not constrained by a specific supplier in its capacity of adopting a

sustainable innovation [61]. Current approaches to develop integrated technology

systems lack models to elaborate on required integrations without the restrictions

imposed by technology dependencies [189]. Such technology dependencies are

obstacles for decisions based on competitive costs and therefore “a barrier for a

sustainable innovation” [61]. As a fast-evolving new science and engineering field,

Informatics Engineering — commonly known as Computer or Software Engineering

— still adopts proprietary or unique approaches to develop each computer or

ITsystem.

The prevailing unique approaches to develop ITsystems and SoS allow the

integration driven by specific adapters or translators to be mediated by integration

hubs or Enterprise Service Bus (ESB) systems [34]. These approaches are discussed

as centralized strategies in relation to the more recent microservices debate [33].

Moreover, the evolution of such integrated solutions is commonly dependent on a

single vendor, known as lock-in problems [71]. Such dependencies are the answer

to innovation processes difficult to base on multi-vendor competitive market

offerings products or services. In the same direction, integration is not always

possible due to interoperability difficulties, at both technical and semantic levels

[189]. An interesting management perspective of this challenge in [162] states that

“The Business of Systems Integration” barely scratched the user perspective. In the

introduction of the referenced book, the following statement reflects closely the

motivations for our research and approach:

Chapter 1. Introduction

2

As business and government users (e.g. airports,

telecommunications service suppliers, energy suppliers, air traffic

controllers, and military organizations) increasingly outsource the

design and production of systems, they need to ensure that they retain

sufficient systems integration capabilities in-house in order to

outsource effectively. This is a major challenge facing the private sector

and governments as they form ‘public-private partnerships’ to build

and install the economic and social infrastructure of the future. [162]

Supporting the user viewpoint, which we identify as user-organization

viewpoint, is the main driver of our research. The difficulty faced by stakeholders

(user-organizations) to properly handle the innovation processes required for the

integration of computer systems, has established the need for openness of the IT SoS

technology landscape, and presenting it as a key research question. Openness stands

for providing vendor-agnostic systems and elements rendering substitutability. Here

substitutability refers to possibility of substitution of a system being technically

possible and financially acceptable, i.e. the user-organizations shall not be

constrained during a procurement process for the required technology or services.

An IT component that we name the Informatics System of Systems (ISoS) landscape

is further considered open when systems or elements are developed under a unified

development culture, making its sourcing sustainable for substitution.

We define the term “Informatics System (Isystem)” as a composite of services

prepared for cooperation, namely its Cooperation Enabled Services (CES). For

instance, a CES abstracts cyber-physical, communication, or software as atomic

elements of an Isystem, which is then a composite of CES elements. The composite

has at least one CES, CES0 that is a meta-element of an Isystem. Taking CES and

Isystem as central concepts, this dissertation sets forth the Informatics System of

Systems (ISoS) through our proposed modularity framework for organization’s

technological landscape. An ISoS technology landscape contains at least one

Isystem, the Isystem0 that is a meta-Isystem of the organization, which would be

open when all Isystems are open. In addition, an Isystem is open when all the CES

that compose the Isystem are open. Thus, a CES is open when there are at least two

substitutable implementations or sourcing alternatives. The research validates

openness at the CES level and allows, with due caution and depending on the

complexity of the application domain, to extrapolate the results at the Isystem level.

If an Isystem follows CES development principles, the substitutability depends on

the conformity of the derived products, following the model adopted by the FIWARE

framework [57].

1 Introduction

3

Due to the high number of existing and potentially conflicting terms (e.g.

enterprise system, information technology system, application, equipment,

infrastructure system), in order to add clarity to the discussion, throughout this thesis,

the term “ITsystem” refers to any legacy system with computing capabilities, for

instance a cyber-physical or embedded system. Furthermore, the “legacy” concept

will be used in this thesis to refer an Isystems not developed under the ISoS

framework. Thus, for a computational responsibility that is developed by following

the proposed ISoS framework, the term Isystem will be used. As further discussed

in Chapter 3, a cyber-physical system can be modeled as a CES or as an Isystem. A

legacy Isystem, can also be wrapped into an Isystem as depicted in Figure 1 and

Figure 2, thus becoming an Isystem afterward.

The proposed ISoS framework is founded on the Service Oriented Architecture

(SOA). The SOA contributed to the evolution of systems integration, from a “tight

coupling” to a “loose coupling” strategy [106]. With SOA, changes in structures of

system’s elements go through the services making the integration less prone to

failures (e.g. due to change of an internal database schema). The ISoS framework

contributes a step further by making the integration “adaptive”, i.e. it adopts an

“adaptive coupling” strategy. The proposed integration strategy relies on meta-data

for CES modularity abstraction for the interactions between Isystems and Isystem’s

elements [145].

To evolve for an open ISoS technology landscape, Isystems need to be

developed to wrap legacy ITsystems. Isystems must implement a reference model,

to render them more substitutability. However, while for CES the result was

validated, the development of reference models for Isystems is identified as a

complex question [120]. Thus, there is a need to draw the industry closer to adopting

a unified development environment, motivating our proposed Collaborative

Enterprise Development Environment (CEDE) platform [149]. CEDE was inspired

by the motivation to guarantee services substitutability, in order to maintain and

evolve in-house developed Isystems. It was also assumed as a strategy to support the

independence of Isystems that may offer capabilities not yet standardized or

requiring then to be adapted to predefined specific requirements. CEDE has been

used to develop reference architectures and reference implementations of CES and

Isystems, thus shielding them from the required standardization process. The

robustness of such a trend for an open ISoS technology landscape however requires

the implementation of certain conformity mechanisms, to validate substitutability for

the implemented products.

The ISoS framework is further adopted in the development of an infrastructure

for Collaborative Networked Organizations (CNO). The integration of collaborative


4

business processes, and the exchange of coordination data is managed by an

Enterprise Collaboration Management (ECoM) approach. The ECoM is an example

of an Isystem that behaves as a unifying infrastructure, functioning to establish an

Enterprise Collaborative Network (ECoNet) i.e. a collaborative platform [159]. The

above mentioned framework and architecture is detailed and exemplified in the

remaining chapters of this thesis.

1.1 Problem Area Motivation Cases

As motivating cases for our research, we address a set of challenges that we have

identified through four real application cases named: ETC, HORUS, SINCRO, and

MIELE. Each case itself represents an initiative, in partnership with private and

public companies, sharing common problems which lead to akin challenging

research questions. The main shared leading problem among the four founding cases

is the need for open enterprise integrating computer systems supporting both intra-

organization and inter-organization domains while responding to innovation

processes under a sustainable approach. The following subchapters introduce the

motivation for each research case.

1.1.1 The Electronic Toll Collection (ETC) case

The development of an open Electronic Toll Collection (ETC) was motivated by the

decision of the company Brisa1 to extend the offered tolling electronic payments,

under the ViaVerde brand, to parking lots and in petrol stations payments, as well as

to regulate the access to urban areas. The initial research project was established in

September 2002 with the Brisa Development and Technology Department, which

first became the Brisa Innovation and Technology in 2008, and then become the A-

To-Be2 company in 2016. The ETC was therefore motivated by the company’s need

to understand difficulties in development of the technology systems answering to the

emerging new business services. The main scientific and technological motivations

for our research were:

• Studying and designing an integration bus able to help them move to a

multivendor sourcing model for the required technology systems;

o The existence of a single supplier was identified as a potential

reason for the overbudget costs;

1 Brisa, a Portuguese company, concessionaire of toll road infrastructures

2 A-To-Be or BIT, Brisa Innovation and Technology, a company of Brisa group

1.1 Problem Area

5

• Understanding how to manage the heterogeneity of the technology

systems in parking lots and the required integration of Road Side

Equipment (RSE) for electronic vehicle identification;

o The need to integrate roadside equipment cyber-physical

systems from heterogeneous parking lots that required specific

developments.

The collaborative dimension was also introduced later (2009) as a requirement,

and the challenge there was related to the exchange of traffic data in DATEX3

standard [119] between Brisa and both the National Mobility Institute (IMT) and

Infrastructures of Portugal (IP), which are public institutes with auditing

responsibilities. For our research, the motivation was:

• The study of a strategy to make the electronic exchange independent

from a single vendor;

o The existing single-vendor solution was identified as an

obstacle for Brisa company when needed to evolve for a new

version of the DATEX standard [119];

• The design of a loose coupling integration strategy for the interactions

between the DATEX data exchange system and the system responsible

for the traffic data.

o The existing DATEX system had direct access to the database

of the traffic data system following a tight coupling connection

between elements of different systems (applications) [99].

1.1.2 The HORUS case

The HORUS case, directed towards the control of the payment of supplies at petrol

stations, started in 2007 with the objective to increase post-payment enforcement

efficiency by Point of Sale (POS) operators. The operator does not authorize the

fueling of vehicles with pending payments, also known as fueling incidents. The

existing system helped enforcement by managing license plates of vehicles with

fueling incidents. The introduced license plates were obtained through visual

examination of surveillance video system recordings based on the date-time of the

fueling incident. Even if an engineering solution existed, the petroleum industry

company Galp4 agreed to invest in our research based on the following motivations:

3 DATEX - Standard for Exchange of traffic messages

4 Galp, a Portuguese petroleum company


6

• The development of a multivendor solution towards automatic payment

enforcement;

o Galp managed petrol stations with POS from different vendors

(Wayne/Gasodata and Petrotec);

o The verification by the POS operator for fueling incidents

required manual access to a different system;

• The development of a strategy to automatically identify vehicles,

making possible for the POS operator to detect in the existing console

a request for fueling from a vehicle with an open fueling incident;

o A manual process existed to obtain the license plate of a vehicle

with a fueling incident. The detection of a vehicle with a

fueling incident was not connected to a specific dispenser,

making it difficult for the operator to validate fueling

authorizations;

o In preliminary research, no standard solution was found, and a

specific solution to be developed was considered with risks of

generating a single vendor dependency since no reference

approach was known.

BP Portugal5 joined the research case in 2013 with the additional motivation of

addressing the collaborative dimension associated with not having to depend on the

petrol station (Galp or BP) to enforce payments. The additional motivation for our

research was:

• The development of a collaborative and technological business

strategy for sharing fueling incidents to make the integration of

systems seamless from the participating companies (Galp and BP).

1.1.3 The SINCRO case

The National Speed Enforcement Network (SINCRO) case was started in 2010 by

the National Road Safety Authority (ANSR) for the development of the Portuguese

national vehicle speed enforcement network. The network was planned to achieve

three hundred enforcement positions (300 cabinets with or without a cinemometer,

from French cinémomètre, requiring a cinemometer from any supplier to plug into

any cabinet) through phased development, considering about thirty enforcement

positions for each tendering process. Before publishing the international tender,

5 BP Portugal, the Portuguese branch of the British Petroleum company

1.1 Problem Area

7

ANSR agreed to support and undertake our research based on the following

motivations:

• The development of a multivendor strategy making each new tender

independent from the deployed systems;

o Most of the existing cinemometer systems in Portugal were

from a single vendor. When police authorities started the

acquisition of cinemometers from another vendor, the

management of enforcement data became problematic since

back-office integration was exclusive for each vendor;

• The development of a strategy for the integration of legacy systems

like the SCoT enforcement management system responsible for the

processing of speed enforcement events from the SINCRO system;

o Technology dependencies were identified based on the trend

to maintain the vendor to avoid risks of moving to a different

company, potentially resulting in risks of sharing existing tacit

knowledge since “Software development is a knowledge-

driven industry” [169];

• The development of a strategy to make the SINCRO cyber-physical

elements (multi-supplier cabinet and cinemometer) plugged into the

legacy monitoring infrastructure.

It was also discussed with Infrastructures of Portugal (IP), The possibility of

access to enforcement nodes installed on roads of their responsibility to obtain the

generated events for statistical purposes. The challenge motivated by our research

on developing a collaborative strategy involving IP and ANSR.

• The development of a strategy to make events from an infrastructure of

the responsibility of ANSR accessible to IP for traffic statistics;

o The need to share access to enforcement events by ANSR and

IP has motivated the research of a strategy to unify data and

coordination exchanges.

1.1.4 The MIELE case

The MIELE (Multimodal Interoperability E-services for Logistics and Environment

sustainability) research case began in 2012 in collaboration with the Administration

of the Port of Lisbon (APL) and the Administration of the port of Leixões/Porto

(APDL) in connection to the European Trans-European Transport Network (TEN-

T). The case aimed at developing a strategy for a MIELE middleware infrastructure

and a strategy for a Port Community System (PCS) as an enhanced Isystem in

relation to the existing port single window (in Portuguese, Janela Única Portuária -


8

JUP) to track containers in the context of the MIELE door-to-door freight

demonstrator. The case researched the door-to-door freight concept manager based

on a Logistics Single Window (LSW) ITsystem as a business platform connecting

ports, customs, and logistics and transport stakeholders ITsystems. The motivations

for our undertaken research were:

• The development of an agnostic technology strategy aiming to reduce

the risks and costs to develop new services. The development of a PCS

with additional services complementing the legacy JUP offerings;

o An assessment of the existing JUP demonstrated a technology

dependency since the technological approach followed a

specific framework of the sourced company;

• The development of a unified strategy to manage business interactions

among stakeholders coping with business in different contexts

(logistics, transports, financing, invoicing, etc.) with their specific data

models and coordination mechanisms.

There is also a main common motivation among the above four research cases

denoted from their growing concern about technology dependencies and the impact

it has on organization’s innovation processes. In other words, when developing new

services, decisions are conditioned by existing suppliers for technology or services

[26]. Another important cross-case concern that we identified is the growing need to

concise business interactions between different organizations, each one with its own

business, processes, and technology culture.

1.2 Problem Area Challenges

The digital and collaborative trend combined with the enterprise integration pressure

to answer the need for innovation processes makes organizations dependent on

specific informatics solutions. At present, the problem dimensions for systems

integration is as follows: the heterogeneity, distribution, and autonomy problems

proposed in [76], which is formulated about twenty years ago, still remains and still

encloses many challenging questions. Therefore, underlying our research is the

proposal of a general framework based on the three dimensions – heterogeneity,

distribution, and autonomy – that we adopt for the discussion of primary challenges

motivating our research the following topics:


9

• Heterogeneity – “Causes for heterogeneity are different database

management and operating systems utilized, as well as the design

autonomy among component systems” [76];

o This represents a dimension with a varying interest about the

heterogeneity level (zero is homogeneity). It can be motivated

by a specific characteristic, e.g. performance, a legacy

technology or an innovative approach to implement a service;

• Distribution – “Much of the distribution is due to the existence of

individual systems before overall systems are built (integration of

legacy systems)” [76];

o This dimension currently holds greater importance since

distribution can be used to improve reliability, e.g. by adopting

Paxos protocol (consensus) for coordinating state replication

[107]. The cloud computing and the elasticity mechanism to

answer scalability requirement is another potential advantage

for distribution beyond autonomy with execution of a system

in different computers;

• Autonomy – “Complex ‘systems of systems’ are characterized by a

controlled and sometimes limited integration of individual autonomous

systems. Often there are conflicts between requirements of integration

and autonomy” [76];

o This dimension relates to our concept of computational

responsibility commonly managed in a sourcing context. The

mentioned conflicts can be associated with limitations or the

type of adopted technology of each autonomous system.

Based on the above classification, that is rooted in [76], we discuss the main

challenges of our research in the following three subchapters.

1.2.1 Vast heterogeneity

In our research cases, internal enterprise and cyber-physical systems crave for open

integrations of enterprise systems in responding to essential new services offerings.

In many cases, the demanded integrations also involve systems in other

organizations. Current approaches to develop both intra- and inter-organization

systems, integration are based on specific protocols and data models through point-

to-point logical connections, as depicted in Figure 1. More recently, such specific

logical connections adopt SOA and Web Services technology. However, despite

using SOA, current technology landscapes result in complex integrations. They

adopt specific mechanisms addressing security, transactions, and reliability for


10

critical systems, therefore making the resulting systems difficult to adapt to changes.

The lack of an adaptive strategy for integrated composites of services in shielding

flexible structure to respond to changes in process-driven approaches, is also

discussed in [182].

Figure 1 – Current architecture of intra- and inter-organizations’ ITsystems

integration

Current technology landscapes based on heterogeneous complex ITsystems are

not well designed since they are one-of-a-kind software products [108]. They do not

consider existing market competitors and do not comply with an open reference

model making them interoperable, i.e. prepared for the required exchanges.

Therefore, legacy ITsystem landscapes are ad-hoc composites of computing and

communication systems for specific application domain as well as any ERP

(Enterprise Resource Planning), CRM (Customer Relationship Management), PLM

(Product Lifecycle Management), etc., or computational responsibilities that are

functioning as adapters, making the necessary transformations to accomplish

interoperability, as shown in Figure 1.

A common aspect of the addressed research cases is the need to integrate cyber-

physical systems as distributed infrastructure equipment with enterprise ITsystems.

However, the current heterogeneity of approaches to their design and development

hinders the coordination of electrotechnical and informatics engineering

competencies. The prevailing approach involves communication protocol for the

interactions, in some cases based on existing standards, extensions or even

proprietary approaches when specific requirement needs specific solutions. This


11

strategy does not enable the adoption of more complex composites, e.g. making the

interaction reliable based on distributed systems coordination mechanisms. This

aspect of supporting a potential advanced composite is further discussed in the

following subchapter.

1.2.2 Distribution

Distribution is another challenging obstacle since the cases are intrinsically scattered

in different locations. The aspects of distribution is not only related to the network

collaborative dimension but also internally to each organization. Beyond the aspect

of autonomy discussed in the next subsection, distribution is currently associated

with the modularity strategy in developing enterprise systems. Among other factors,

distribution can contribute to:

• The reduction of dependency among system components by enabling

them in different execution environments, e.g., a process-intensive

component needing elastic features from a cloud infrastructure;

• A system component from competing suppliers being sourced as an

autonomous entity connected through a local or wide network;

o This might involve parallelization of critical functions to

respond to the expected performance requirement;

• The answer to fault tolerance requirement creating the need to develop

some degree of fault tolerance as a mechanism to properly respond to

the assumed failure risks.

The coordination of distributed components or elements of a system is complex

since failure and inconsistencies may occur for several reasons, from physical clock

drifts to communication or component failure. This makes the development of

reliable systems or elements of a system a challenging endeavor.

Therefore, one main challenge from the distribution dimension is to streamline

the development of integrated systems as composites incorporating contributions

from specialized areas, namely distributed systems with fault tolerance mechanisms.

1.2.3 Autonomy

The Autonomy dimension remains challenging in its essence. Furthermore, the

integration of autonomous ITsystems is challenging since each one interprets

requirements differently and adopts different designs, models, and implementation

strategies. To maintain the integrity of such autonomous systems, mediation

enterprise systems are adopted. Integration hubs or enterprise service buses for the

intra-organization and specialized ITsystems as adapters for the exchange of


12

business and coordination data in an inter-organization context constitutes an

adopted pattern. Therefore, while autonomy is important since the required openness

of the technology landscape is a major challenge, there is a need for a common

framework able to accommodate heterogeneity, distribution, and autonomy in a

seamless manner.

The main challenge is therefore to develop a strategy and a modeling framework

allowing to cope with such three dimensions, as rooted in [76], where the dimensions

heterogeneity, distribution, and autonomy are maintained as driving strategies

towards an open technology landscape. In our approach we consider the

collaborative dimension from a unified Isystem with the role to manage business and

coordination exchanges and interactions in a centralized way, as represented by the

Isystem C that is depicted in Figure 2. However, still the most important aspect is to

support the following:

• Heterogeneity – Establish an adaptive mechanism able to hide

heterogeneity, as a strategy to make it possible to accommodate

diversity and as such to join two advantage factors: value the legacy

practices and, at the same time, render the adoption of technology

innovations seamless and sustainable. Here seamless means without

having the need to change suppliers’ development culture, and

sustainable means supporting the substitutability principle;

• Distribution – The challenge has to provide a distributed technology

landscape with the possibility to adopt advanced fault tolerance and

scalability strategies while maintaining the technology solution open;

• Autonomy – Given the complexity of the discussed technology

landscapes, the independence of each component that is required to

have multiple sourcing shall be autonomous. This means that with

such adaptive-coupling approach, the risks of mutual interference are

reduced.


13

Figure 2 - The strategy for challenging ITsystems towards Isystems

Our research has therefore targeted the construction of an alternative modeling

strategy considering these high level three dimensions with mechanisms to a

desirable approach coping with specific features for each one. Thus, our challenge is

to develop an informatics technology framework able to adapt the systems developed

in different technology. Consequently, developing a framework that makes possible

the integration of systems or elements of systems developed in different technologies

(heterogeneity), reliable (distribution), and adaptable (autonomous). Such features

are quite challenging to achieve since technology aspects are often tightly associated

with business needs, requiring an abstraction effort to make them answer to changes

under sustainable solutions.

An additional important challenge in our approach is to design a strategy

towards a sustainable adoption of both the standards and specific unique technology

systems. It is of paramount importance to avoid dependency situations as discussed

in [180] of a computer manufacturer holding legacy product lifecycle management

(PLM) systems, facing issues to follow client’s changes. Even if a SOA wrapper,

based on Web Services was developed, the complexity of the solution suggests a

more generic framework to cope with the integration challenges. To the best of our

knowledge no specific research was found discussing the specific aspect of

innovation constrained by technology dependencies. There is however a discussion

in [162] (“Towards a Dynamics of Modularity – a Cyclical Model of Technical

Advance”), related to hard disk manufacturers, demonstrating risks of losing

competitiveness when outsourcing the development of key components without


14

maintaining knowledge to develop and integrate them. Their research shows “the

enduring value of retaining systems integration knowledge”, which is what we

extrapolate to the informatics domain as a key challenge for our approach to achieve

agnostic technology landscapes, through reducing technology dependencies risks.

1.3 Research Methodology

Our research follows the Design Science Research (DSR) approach [79], [197]. DSR

is a method of scientific research that considers development of artifacts in a problem

context or domain. Artifacts correspond to research objects in context. The context

refers to the problem domain addressed by the research and is where the knowledge

about the artifact is questioned. From this cognitive process are potentially generated

knowledge and new strategies of approaching to the target artifact [197].

We have established as the context in our work, the development of an Open

Integrated Informatics Technology Landscape. The main thread of our research has

been focused on the approaches for existing open market and how to address

innovation processes challenged through an open perspective (multi-supplier

technical solutions). The context also includes the research of technology

infrastructure for collaborative networks. To better frame the artifacts and research

context, Figure 3 depicts a simplified view of the Design Science Framework (DSF)

proposed by [197], and instantiated with aspects of our research.

The research (Investigation) box in Figure 3 refers to the context in our research,

i.e. the open integrated informatics systems and the collaborative network. Social

context, who sets goals and requirements, finances and benefits from the created

value, which means the stakeholders that motivated the research (Brisa/A-To-Be,

Galp and BP, ANSR, and APL and APDL). The research was founded on informatics

theories and tools generally targeting the Intelligent Transport Systems (ITS) as the

main target research domain.

The design box, the Artifacts object of our research, refers primarily to two

contributions, the ISoS framework with its CES and Isystem concepts, and as a

secondary result the ECoNet collaborative network infrastructure and the ECoM, as

the validation means for our proposed ISoS. To streamline the mapping of our

research for the DSF, the knowledge context box was not included in Figure 3.

Nonetheless, it is important to emphasize that the practice knowledge for the design

of the proposed Artifacts is also considered.


15

Figure 3 – Projection of research in the Design Science Framework; adapted from

[197]

The research, spanning the period 2002 to 2017, grounds on the four cases

presented in subsection 1.1 and the associated research objectives that are presented

and discussed in the next subsection, as also presented in Figure 4, our research

began with the identification by Brisa company of the need to rethink their electronic

toll collection, due to its technology dependencies which were clearly identified as a

main obstacle to the underway innovation of payment services, further extended to

parking lots and fueling stations. We therefore defined our first research objective

(RO.1), to develop a service integration bus in response to which as addressed in

Chapter 3, we have designed and developed the Intelligent Transport Systems

Interoperability Bus (ITSIBus). The ITSIBus represents our initial formulation of

modularity abstraction, based on SOA and on adopting the JINI/Java framework

[147], [157]. However, in spite of its effective support for a multi-supplier approach

for the Electronic Toll Collection (ETC) (as detailed in Chapter 3), its dependency

to the Java/JINI specific technology was in fact an obstacle for facilitating its

adoption by the industry.


16

Figure 4 – Timeline and research objectives considered in the development of the

ISoS framework

Therefore, the ITSIBus approach, developed in the context of the ETC case,

was in fact regarded as a short-term solution for our research target. Further on, we

defined adaptive modularity as our second research objective (RO.2), and developed

the Cooperation Enabled System/Services (CES) [145], which establishes a general

and enhanced model towards our final solution, while enforcing no specific

technology dependency. The CES model is developed, and matured as a

complementary approach, over this timeline, as presented and discussed in Chapter

4.

Also as part of RO.2 to cope with substitutability in the organization’s

technology landscape, we then proposed the Informatics System of Systems (ISoS)

[120], also presented and discussed in Chapter 4. The ISoS establishes our central

model to support the open informatics and cyber-physical technology, led by the

substitutability requirement, and towards the development of vendor independence

systems, components, and services.

We continued applying our research results and developments in three other

industry cases of HORUS, MIELE, and SINCRO, and discovered more challenges,

that resulted in new research objectives. Although CES was prototyped, its

application in production required its market adoption. But clearly, the suppliers of

products and services preferred maintaining their own culture and practice, also as a

strategy to achieve market leadership. So, we needed to approach challenging such

practices manners through the large and public user-organizations, who in fact

sponsored our further research on this topic. We therefore defined our third research

objective (RO.3) to address a unified development strategy in response to which we

have designed and developed the Collaborative Development Environment (CEDE)


17

as a unified workbench to reduce technology dependency [149], as discussed in

Chapter 5.

Furthermore, primarily motivated by the need for industry partners

collaboration in the MIELE case, we defined our fourth research objective (RO.4),

in response to which, we designed and developed ISoS for the CN, and the Enterprise

Collaboration Network (ECoNet) [159]. These structure the cooperation between

Isystems in networked organizations. The ECoNet and its related concepts, namely

the Enterprise Collaboration Manager (ECoM), Collaboration Contexts (CoC),

Collaboration Context Service (CCS), and Virtual Collaboration Context (VCC) are

also discussed in detail in Chapter 5.

1.4 Research Questions

The development of informatics systems and system of systems lacks an open

technology and lifecycle management models. The growing need for higher

integration levels has been establishing complex critical technology landscapes. This

trend has contributed to the generation of ad-hoc integration solutions, establishing

strong vendor/producer dependency, i.e. the vendor lock-in problem [39], [61], [71],

[140]. Existing integration strategies are based on adapters or integration brokers,

themselves proprietary developments adopting low-level standards (HTTP, SQL,

FTP, SOAP, RESTful, and others), and not following an implementation based on

an open reference architecture. Such growing chaos needs a grounded approach from

three main perspectives: i) the structuration of the computational responsibilities -

Isystems representing autonomous responsibilities implementing a set of services;

ii) the unification of the development culture, based on common frameworks,

languages, and tools; and iii) an open governance model able to establish trusted

management and maintenance (operations management) of the set of Isystems

cooperating as a coordinated composite system, therefore as an integrated Isystem.

In this thesis, we discuss these three perspectives at different levels of

abstraction, demonstrating that the ISoS framework can support adopting CES

elements from at least two competing suppliers. While our research has led to

valuable results already adopted by industry and services organizations, it

contributes to research a developing open complex system of systems both intra- and

inter-organization. Our approach also contributes to addressing collaboration

challenges in a complex network like the one depicted in Figure 5, where any

organization is free to decide at any time the best supplier for each Isystem that is

part of its informatics composite.


18

Figure 5 – The inter-organization IT integration strategy

As discussed throughout the thesis, achieving the above “ambition” is still far

from reality. However, our approach demonstrates through a set of experiments and

real use case implementations that the models we have designed and formalized

provides an effective contribution towards reaching such an ambitious endeavor.

This research was driven by theoretical background and study of real problems

faced by large private Portuguese and international companies (e.g. Brisa,

Galp/Galpgeste, and BP Portugal), and by public enterprises and authorities (ANSR,

and APL/APDL in Portugal). We defined our overarching research question as

follows:

How to establish a multi-vendor informatics technology landscape

to support the emergent innovative integrated services, when involving

a network of stakeholders, e.g. providing the single window, while

considering the current chaos that organizations are facing to manage

their assortment of (legacy) Isystems - in most cases representing

“automation islands” – and where new and legacy systems have been

integrated through ad hoc strategies, leading to strong technology

dependencies and vendor lock-in?

The service concept, applied to information technology, has been used from

complementary perspectives as a structuring strategy for setting-up its elements,

hence establishing loose coupling strategies to link (distributed) computational

1.4 Research Questions

19

entities, each one with its own lifecycle development and management processes.

However, service orientation is not enough considering the existence of many

technologies and design cultures. Extending services to the inter-organization

domain further complicate the design of coordinated models for the interactions

between heterogeneous enterprise systems, as a growing number of innovation

processes are grounded on networked organizations. This trend is further accelerated

by the low cost, high throughput, and reliable communication resources. However,

the infrastructure of the inter-organizations can’t be dissociated from intra-

organization infrastructures. Based on this assumption, and aimed at justifying our

ambitious holistic approach, the following solution was hypothesized:

Multiple providers and multiple technologies used in (legacy)

Isystems, represent their computational responsibilities. These so-

called responsibilities establish their set of capabilities to address a set

of requirements. Such capabilities are operationalized by an Isystem

developed for the cooperation with other peer Isystems, all

implementing a set of services. Such Isystems are developed under a

unified development and operational framework. Furthermore, one of

these Isystems, under an open specifications model, would be

responsible for managing and operating all data exchanges among all

organizations.

To test and validate these hypotheses a set of more focused Research Objectives

(ROs) was defined:

RO.1 Definition of an integration strategy (bus) of heterogeneous

informatics systems and cyber-physical systems from different

suppliers.

RO.2 Construction of an open adaptive modularity framework,

making it possible for multi-supplier cooperating technology

systems and elements to be developed under different

technology cultures.

RO.3 Establishment of a development and deployment strategy to

cope with the difficulty of adopting supplier independent

technology systems and services in building large system of

systems.

RO.4 Construction of an open, collaborative infrastructure,

enforcing organization's modularity framework, in the context

of collaborative networks where heterogeneous technology


20

artifacts developed under different administrative domains,

need to cooperate.

In our approach to addressing the above challenges within open ISoS, our

research considers the electronic data interchanges across organizations as a

complementary dimension formulated based on a model for the management of the

business collaboration, considered important to complement the validation of the

proposed modularity framework. Based on the common business collaboration

practice to manage business correspondence followed by organizations, processed

and dispatched by a dedicated correspondence department, the concept of a generic

open collaboration broker (the Enterprise Collaboration Manager – ECoM, as

depicted in Figure 5 is proposed. ECoM is aligned with recent development in

distributed and communication systems and contributes to fulfilling the needs for a

scalable and cheaper computational infrastructure. This has led to the proposal of an

open, collaborative networked organization infrastructure, made of Isystems playing

the role of "open bridge" between the network and the intra-organization's culture.

1.5 Design Challenges for Open ISoS

A main challenge for the emergent complex information systems is how to establish

a modular framework able to address openness and substitutability principle. This

means that architectural decisions shall be bounded to well-established

computational responsibilities, able to be substituted by an alternative from a

competing provider. However, substitution of parts or system elements (subsystems)

of a complex Isystem require that its modularity/granularity follow a reference

architecture, where each subsystem has a well-defined set of capabilities and

interfaces.

Furthermore, developing an open modularity framework at higher levels

requires careful addressing of both the functional and nonfunctional capabilities, as

well as the agreements with respect to business processes, rules, and data models. In

this thesis an evolving approach based on a set of design requirements is discussed

and proposed, namely addressing the following aspects of the framework:

Independence (autonomy) of a substitutable Isystem (loose coupling) – it shall

be developed for cooperation and instantiated independently from the other Isystems

on which it depends (and cooperates with). If the Isystem on which it depends fails,

the behavior should follow some planned recovery thread.

1.5 Design Challenges for Open ISoS

21

Life-cycle management – integrated life-cycle management considering

procurement/development, deployment, operations, monitoring, and maintenance

(including evolution, an update of new releases) needs to be established, related and

coordinated with the adopted governance model and management tools.

Freedom of technology approaches – this is a major challenge, considering the

evolution in informatics science and engineering area, and the diversity of

programming languages (C/C++, Java, C#, {P, C, J}thon, Cobol, Fortran, Prolog,

Lisp, JavaSript, from others), frameworks (.NET/WCF, Java/JEE/OSGi, logging,

remoting, distributed services, messaging, events management, security,

authentication, from others), Integrated Development Environment (IDE) tools

(Visual Studio, Eclipse, NetBeans, JDeveloper, IntelliJ IDEA, from others), and

many other paradigms that are in some cases difficult to classify considering that

some of them share similar features. Here, convergence is necessary, but it is also

important to accommodate novelties resulting from scientific and entrepreneurial

efforts.

Execution environment independence – with a novel industrial approach to

virtualization through what is now identified as cloud computing, execution

environments have become more flexible, elastic and ubiquitous. Nevertheless, even

if three main service models exist – Infrastructure as a Service (IaaS), Platform as a

Service (PaaS), and Software as a Service (SaaS) – a fully standard open cloud model

is still lacking. The issue is more pressing when there is a need to adopt hybrid

solutions considering dependability, security, and cost constraints.

Distributed coordination, federation – the requirements for ISoS are

provisioned through distributed autonomous components (multi-supplier Isystem),

in some cases in an inter-organization scenario. In such complex environments of

data exchange and sharing, in the form of messages or events (complex event

systems) and in some cases involving a huge number of elements, the global

consistency is difficult to maintain. The detection/identification of such

inconsistencies needs to support upper layer decisions and to provoke controlled

failures and subsequent recovery procedures.

Reliability – the Isystems cooperate for critical processes, where failures are not

acceptable. Furthermore, the modeling of failures and recovery mechanisms are

additional challenges associated with multi-supplier and reliable ISoS.

The discussion motivated by the Consistency Availability Partitions (CAP)

theorem [20], [19], emphasis that in principle it is not possible to develop an ideal

distributed Isystem of systems, that is an Isystem that does not fail under any

circumstances, which is important to consider for our discussion. Nevertheless, it is


22

of paramount importance to find an ISoS designed that can assure reliability, and

consider that our selected application domains involve critical processes, meaning

that our proposed technology infrastructure shall properly implement the necessary

coordination and recovery (or fault tolerance) mechanisms. In other words, failure

cannot occur and be later proved to have resulted from an incorrect design option.

This might imply a professional responsibility with a disastrous impact, that is the

failure that results in loss of lives or properties. Addressing this specific last aspect

falls outside the scope of this thesis and our current research does not directly

contribute to these specific concerns. However, these are important for the

construction of a scientifically grounded design of complex ISoS as we also later

discuss in Chapter 6. There are also specific concerns when such systems are

developed for critical (life-dependent) application domains [183], [23], [43], [195].

1.6 ISoS and Collaborative Networks

Operation and coordination of interactions between Isystems needed for the

development of Collaborative Networks (CN) are challenging. The CN is a fast-

evolving multidisciplinary scientific area aimed at establishing complex relations

needed for creating the networks, based on various approaches addressing study of

protocols, theories, modeling, and simulation. Beyond the organizational, business,

and people inter-relations, the underlying technology landscape has been the object

of our research, giving rise to strategies to structure a complex network of Isystems

[130]. Diversity of technology cultures in such a federation of networked

organizations makes it challenging to maintain a complex distributed system

supporting both intra and inter CN coordination. Furthermore, the technology

dependencies become an added concern for the inter-organizations’ context, where

critical business depends on an adaptive and reliable collaborative infrastructure.

The state of the art reports a growing adoption of peer-to-peer relations based

on dedicated data interchanges using EDI/EDIFACT or similar standard protocols

[54]. The adoption of point-to-point interactive models has experienced many

integration problems. In many cases, ad hoc integration strategies are developed to

deploy specialized adapters to manage the interchanges and the required mapping to

adapt data model differences. Such adaptations are made under tight coupling data

sharing mechanisms (in some cases, based on direct database accesses) giving rise

to complex dedicated technology deployments which are burdensome to support. As

they are specific software solutions, in most cases without open well-founded

architectural approaches, only their original developers can answer needs for

changes. These technology dependencies have been an obstacle for the development

of collaborative networks considering the difficulty (and costs) of establishing a


23

reliable technology landscape for the operation, coordination, and management of

the complex data and coordination interchanges, on the assumption that nodes are

potentially supported by a diversity of technology cultures.

As a contribution to this challenge, this thesis presents an approach based on a

federation of organizations as nodes of an abstract unified network, the Enterprise

Collaborative Network (ECoNet) [146], [159], operationalized by an Enterprise

Collaboration Manager (ECoM) as the unique Isystem responsible for the

operations, management, and coordination of the data exchanges required by any

other Isystem of any (ECoNet enabled or prepared) networked organization.

Furthermore, in addition to a contribution to the Infrastructure for Collaborative

Networked Organizations (CNO), the proposed approach also includes a strategy for

an Isystem modularity framework able to contribute to the development of agnostic

ISoS. This lower-level model formulation is based on the Cooperative Enabled

System (CES) [145], aimed at abstract software development specificities under

software and hardware system abstraction. Our approach aims to answer real cases

grounded on tight and specific solutions, where specialized adapters or integration

hubs lack an open reference architecture, thus leading to technology dependencies

that are difficult to manage. The growing complexity of the data interchanges and

coordination requirements underlying collaborations need to guarantee the level of

reliability and security required. Therefore, it is of paramount importance that the

computing systems from different cultures (networked organizations) are able to

work together. The EcoNet system developed in the context of this thesis is based

on an open reference architecture and implementation grounded on the concept of a

collaboration mediator responsible for managing collaborations. The ECoNet key

Isystem ECoM acts as a unifier of the existing adapters which are abstracted as

Collaboration Contexts (CoC), as shown in Figure 6.


24

Figure 6 – Collaborative Networked Organizations linked by ECoNet Infrastructure

Any supplier of any organization’s Isystem is invited to join the ECoNet

collaboration infrastructure by evolving its product to cooperate with ECoM to

access collaboration services. Through the ECoM, any organization’s Isystem can

look for a business partner, manage its business relations with bounded groups,

named Virtual Collaboration Context (VCC), from other management and

coordination services. One major aspect underpinning our approach is related to the

simplicity and the adoption of a minimal set of common agreed concepts and

implementations, able to improve re-utilization and manageability of the huge

number of heterogeneous and distributed Isystems that sustain the emergent

collaborative networks. While the ECoNet infrastructure does not impose a structure

for the modularity of the autonomous (multi-supplier) computational

responsibilities, the theoretical model assumes that any CoC follows the Cooperation

Enabled System (CES) reference modularity model. However, to maintain the

dependencies on implementation strategies as loose as possible, internally a CoC as

part of a CES instance is free to follow a specific architectural approach and

technology and development options (culture-specific). Nevertheless, the re-

utilization of components across collaboration contexts requires a CoC element

thoroughly to comply with the CES modularity model.

The proposed ISoS framework goes further than the initial research objective

of an integration strategy (RO.1), by establishing an open adaptive modularity

framework (RO.2) towards agnostic system of systems. Furthermore, the diversity

of technology and development paradigms has motivated the CEDE initiative as a


25

unified approach to development and deployment (RO.3). Also, the structuration of

the inter organizations relationships through the proposed ECoNet collaborative

infrastructure extends our approach to the collaborative networks (CN), through the

proposed modularity framework, facilitating cooperation among Isystems in

different administrative domains (RO.4).

1.7 Thesis Structure

The remaining chapters of this thesis are organized as follows:

Chapter 2 presents the state of the art about systems integration and

collaborative network infrastructures aimed at demonstrating the need for a novel

structuration of the complex distributed Isystem composed of heterogeneous

Isystems. For this purpose, the Intelligent Transport Systems (ITS) are explored as a

challenging application domain with a diversity of research cases aiming to achieve

novel approaches to address the growing complexity. The research efforts in the fast-

evolving Collaborative Networks (CN) community are also surveyed and discussed

with a specific focus on computational frameworks that are able to potentially meet

requirements. The state of the art is also mapped to our proposed research questions,

bridging other key research contributions to our research approach.

In Chapter 3, the research objective of defining an integration strategy (RO.1)

for heterogeneous informatics and cyber-physical systems from different suppliers

is answered through the proposed initial Intelligent Transport Systems

Interoperability Bus (ITSIBus). The ITSIBus as a service-oriented framework for an

electronic toll collection (ETC) informatics system is presented and discussed. The

adopted service abstraction mechanism that decouples computational

responsibilities, and facilitate operational interoperability in the ETC case, is

discussed and mapped to the primary problem.

In Chapter 4, the research objective of constructing an open adaptive modularity

framework (RO.2) is proposed and explained. The open modularity Cooperation

Enabled System (CES) as a central adaptive strategy for service/system integration

is formulated and discussed. It is further framed into the Isystem of systems (ISoS)

founded on the concept of Isystem0. Our approach is rooted in supporting many

challenges faced in the Brisa, ANSR and HORUS cases, as examples of adopting

multi-supplier technology solutions. Our proposed models demonstrate contributing

to multi-supplier cooperating technology systems and elements, and resulting cost

advantages.


26

In Chapter 5, two main research objectives are addressed, including: i) The

establishment of a development and deployment strategy to cope with the difficulty

of adopting supplier independent technology systems and services (RO.3); and ii)

the construction of an open, collaborative infrastructure based on the organization's

modularity framework in the context of collaborative networks where heterogeneous

technology artifacts under different administrative domains need to cooperate

(RO.4). In relation to RO.3 the Collaborative Engineering Development

Environment (CEDE) workbench is presented and discussed as a unified

development environment as a strategy for the convergence of open multi-supplier

solutions. A pilot in the MIELE case demonstrates the exchange of tracking

messages in the context of a door-to-door container tracking solution. The ISoS and

the proposed CES are discussed in the context of the Enterprise Collaborative

Network (ECoNet) infrastructure in answering to RO.4. It is an application case for

the proposed framework, considering both integration at the intra-organization level,

through the open coupling infrastructure based on the Isystem0 concept, and the

inter-organization level, through the ECoNet collaborative platform (ECoM

Isystem).

In chapter 6, four validation cases, including: ETC, HORUS, SINCRO, and

MIELE, are presented and discussed. Validation metrics and a validation

methodology are proposed to access the developed models in the context of the

research cases. In the last section, the achieved results are assessed. Furthermore, a

mapping of research objectives and achieved results from the developed research

cases are also discussed. An important result common to all our considered research

cases is the relationship between a multi-supplier approach and the sustainability of

heterogeneous technology solutions, measured through the obtained reduction in

costs.

In chapter 7, conclusions and further research plans are presented and discussed.

Among the lessons we learned through our research, we discovered that achieving

our proposed research goals requires that the user-organizations take the leadership

in enforcing the convergence to a common framework. This is against the current de

facto leadership in service development, which is in the hands of software

development industry, that depending on their market size, each of them pushes for

their own applied technology. This trend needs to move towards open multi-supplier

technology setups that allows for competing but collaborative integrated business

frameworks to co-exist as supported and promoted in this thesis.

27

Chapter 2

2 Related Research -

Developing Open Informatics

System of Systems

The openness of informatics systems has been considered a requirement for

sustainable integrated informatics solutions. i.e. both computational technology and

application domain elements shall support satisfying the associated (formulated)

requirements, including the essential vendor agnostic condition. The complexity of

systems increases with the trend of “total integration” systems, composed of a

diverse technology and process cultures due to the current vendor lock-in

approaches. We refer to such computational centric system of systems, as

informatics system of informatics systems (Isystem of systems) or in its simplified

form as Isystem of Systems (ISoS). ISoS needs a novel structure able to answer both

intra and inter-organization’s Isystem of systems integration requirements.

Furthermore, the complexity is extended with the collaborative dimension, since

business interactions among organization are becoming digital and require the

integration of Isystems managed by heterogeneous processes and technology

landscapes. In this chapter, we present and discuss important contributions from

relevant literature that directly or indirectly provide scientific, technological or

strategic contributions to this area.

Since the primordium of computing as a science and engineering, the focus has

been centered on software development. Moreover, the need to explore parts to

develop strategies to address specific application domains has delayed the

investment in developing a holistic solution to the problem [111]. The research

studying data integration using web services “used to unlock heterogeneous business

systems to extract and integrate business data” [75] and the more recent research

studying the changes to business processes in an integrated systems landscape [89],

Chapter 2 Related Research

28

demonstrates such a dispersion. In fact, the need to make improvements in a diversity

of specific application domains has blurred the development of a holistic strategy of

open informatics systems. Research in computer architecture, federated database

modeling and management, business process modeling, distributed systems, and

artificial intelligence, to mention just a few, have been based on a diversity of

backgrounds and approaches, many of them built on industry pragmatisms,

producing an array of models, specifications, protocols, frameworks, and other

paradigms difficult to unify towards an integrated vision.

The following state of the art study covers innovative “islands of approaches”

where informatics systems developed based on industry-specific cultures, is proven

to be difficult to manage, integrate, and evolve [170]. An oversimplification of

complexity through delimitation of approaches and validations is recurrent in

research works. The discussion about SOA as a key approach to achieving

integration among heterogeneous systems can be presented as an “intelligent service

infrastructure that drives and simplifies service reuse and delivers reliable

integration across an inherently heterogeneous, multi-vendor computing

landscape”. While such argument might be true for the limited discussed scenario in

[100], it is not a well-founded approach to solve the complex integration problem of

the multi-vendor system of systems, in both the intra-organizations or for the system

elements of the collaborative network system of interest.

This chapter reviews the state of art of research and practice centered on the

challenge to develop open (agnostic) integrated informatics systems in both intra and

inter-organizations, centered on structuring the informatics and cyber-physical

technology landscape with a focus on openness of approaches (vendor agnostic).

Past and current initiatives targeted to contribute to an open modularity framework

to frame such Isystems networked (distributed), under different governance

responsibilities for both intra and inter-organization interactions are presented and

discussed. Relevant contributions related to the challenged research are presented

and discussed along the following sections, such as ambiguity of the terminology,

vendor lock-in issue, openness of solutions, substitutability concept, required

modularity abstraction, integration of heterogeneous contributions, integration with

cyber systems, integration of enterprise informatics systems, and integration at the

collaborative dimension. It aims at positioning the research on the state of the art as

a foundation of the proposed ISoS framework. Despite being grounded on service-

oriented (SOA) models and concepts, the ISoS adopts a novel adaptive approach to

cope with the recognized difficulty in evolving towards unifying informatics

technology paradigms. In section 2.1, we discuss the complexity of developing

informatics systems. In section 2.2 and 2.3, we present the modularity framework

2.1 Informatics Systems Specifics - Isystems

29

and review the role of web technologies. Section 2.4 discusses the details of the

development of reference architectures and frameworks as a key contribution to

unifying approaches. Section 2.5 addresses the integration from cyber-physical

sensing or acting to back-office systems. Finally, in section 2.7 we present the

integration strategies at both intra and inter-organizations levels. The chapter ends

with a short conclusion.

Sections 2.1, 2.2, 2.3, 2.4, 2.5 and 2.7 address related research, considering

discussions about the complexity of computing systems, and standardization

initiatives, among other related topics. Section 2.6 references the FIWARE as an

approach partially related to our proposed model, since it considers the development

of reference models and reference implementation that we also adopt in our proposal.


The development of complex systems is a long-discussed research topic and a

concern among the industry and the community. In 1972, Liskov [117] discussed

reliability and complexity associated with software developments. At that time, the

concern was not the vendor-agnostic but rather the complexity of developing reliable

software systems. The introduction of the term complexity in [117] refers to, on the

one hand, the potential extensive number of system states and the difficulty to

manage the business logic handling them and, on the other hand “… the efforts of

many individuals must be coordinated in order to build the system”. It is quite

interesting that more than four decades later we are still discussing the same kind of

problem. While nowadays the complexity might have increased, and the state of the

knowledge about computer science and engineering and available resources have

evolved, we are still unable to offer reliability for the new integrated and distributed

system of systems. Such reliability is difficult to guarantee in a multi-supplier

environment as they have different processes and technology cultures while

collaborating for the life cycle management of integrated ISoS. In the following two

subsections, the discussion is centered on the gap between informatics engineering

and the diversity of domain knowledge (application domains). The aim is to further

discuss the trend for a system engineering approach as a strategy for answering

requirements from a model-based systems engineering (MBSE) perspective [45].

2.1.1 Gap between informatics engineering expertise and domain

knowledge

The recurrent challenge to manage the frontier between the informatics engineering

expertise and the (application) domain knowledge, e.g., management, accounting,


30

and logistics poses an additional constraint. This border between technology and

processes, also referenced as the “gap”, has been recognized for long [123]. Finding

the best strategies to accommodate fast-evolving requirements in various application

domains and answering expectations to adaptive processes automation has been a

long-standing science and engineering challenge. In recent works [77] [123],

inefficiency and ineffectiveness are identified as an obstacle to managing relations

between business and informatics systems actors. The proposed approach explores a

relationship management framework to moderate requirements changes towards

improving the relations between Informatics Technology (IT) and business

colleagues based on social capital theory. It is quite interesting to see similar

concerns addressed from different converging viewpoints, such as technology,

business or management. In recent research, [185] is addressed in that “Technology

shifts are lethal to many manufacturing companies”, where the use of lethal

emphasizes a real problem for which the authors suggest a compound approach for

technology and service innovation.

For reducing such a gap, the development of informatics systems is evolving

with a diversity of contributions, e.g., a rule-driven technology adoption based on an

initial identification of documents and data elements proposed in [51], which is

intended to address the discussed complexity with a too much intrusive approach

between functional statements and technological decisions. The cyber-physical

systems research community has been studying the “gap” reduction between

technology and processes that is being addressed through the Software Platform

Embedded Systems as a modeling framework to bring closer systems engineering

and software engineering based on the system life cycle processes standard ISO/IEC

15288 and the software life cycle processes standard ISO/IEC 12207.

Notwithstanding the value of the proposed approach, since the problem at hand needs

more than just a bridge between systems and software engineering, one possible path

is to first think about informatics systems as systems engineering and, when the

responsibility boundaries are clearly defined, then pondering software development

issues, as further discussed in the next section.

2.1.2 Informatics system engineering

The review of research work on software engineering for ubiquitous systems [72]

shows a diversity of approaches, technologies, tools, and frameworks, and in general

terms, the research concludes that further research is needed. The lack of a clear

collaboration border between systems engineering and software engineering has led

to a complex and challenging to grasp and manage a web of concepts, technologies,

and models. The relationship between systems engineering and software engineering


31

is discussed in [163] by professionals, academics, the industry, and the government,

around the following aspects: i) development, ii) technology, iii) people and iv)

education, where the main achievements point to the need for the improvement of

synergies and the clarification of roles and responsibilities. In A Journey Through

the Systems Landscape [111], which contributed to the mentioned discussion, the

only mentioned engineering area related to computer science and engineering is

software engineering (and not as suggested by this thesis, e.g., Informatics

Engineering).

The ambiguity in the use of the terminology related to software engineering is

another obstacle for a unifying approach. Depending on the background of the

speaker/writer, it is more common to find software engineering than engineering (be

it information system, computer, information security, distributed systems, agents,

and intelligent systems). The ACM/IEEE Computer science curricula 2013, which

established the body of knowledge of computer science field, defines the following

main areas, i) Computer Engineering, ii) Information Systems, iii) Information

Technology, iv) Software Engineering, and v) Computer Science. The engineering

perspective is only associated with computer and software. In the synthesis report

[171], the proposed eighty knowledge areas are summarized without any reference

other than systems or software engineering. This ambiguity in the classification can

be removed if instead of software engineering, a knowledge body on Informatics

Engineering is adopted. It might carry the advantage of the systems science and

engineering arguments for establishing a stronger and coherent structure for the

existing fragmentation. The idea is to delimitate the suite of specialized computing-

related knowledge bodies in a more coherent composite able to rearrange the current

complexity into a unified science and engineering discipline. We argue that there is

a need for such shift as a valuable approach to aggregate the diversity of expertise

from infrastructures to business and computational intelligence areas. The idea is to

think about software development as a key contributor for the informatics systems

engineering by shifting its current central role to an autonomous software

engineering area. This concern towards a clearer separation between informatics

systems and software engineering is patent in a change for the increasing importance

of systems and system of systems approaches.

Systems engineering is a multi-engineering approach for the development of

complex systems spanning various disciplines. In [45], a system engineering design

and analysis is suggested. After identifying the system elements and required

competencies, a “Downstream Engineering” process assigns the corresponding

systems or system elements to the specialized engineering competencies. The same

author defines Integration as being “all about bringing different things together into


32

a coherent whole” to argue about the need for such a multi-engineering layer

abstracted through a Model-Based Systems Engineering approach for establishing

required specialized engineering contributions. The approach seems interesting

since, in most of the research cases supporting the thesis, a system contains elements

from different engineering disciplines, e.g., an electronic toll collection (ETC)

system includes roadside equipment (RSE) to identify vehicles on a radio frequency

technology basis. The RSE is an example of a cyber-physical system for which the

electrotechnical engineers are commonly responsible for.

The complexity of software systems as addressed in section 2.1, considering

that it represents compositions of heterogeneous setups described in the mentioned

related research, is a good of the trend in emerging systems development. As the

main foundation for our proposed concept of Informatics System (Isystem) we focus

on and support all these complexities.

2.2 Open Modularity Frameworks

The distinction between systems thinking and software developments lead us to the

discussion of the modularity as a key issue for the development of the open Isystem

of systems (ISoS). Modularity is defined in [179] as “the level of independence of a

component from the other components within a product” emphasizing the

independence of the composing blocks and proposing a modularity degree based on

the number of interdependencies. By formulating a theory of modularity in [65], the

challenge is approached from the semantics, the benefits, the exclusiveness of

patterns, the natural properties (predictability of properties), and concise methods

supporting modularity. The Modular Architecture Functional Distribution (MAFD)

in [65] is a mathematical formalization proposed to describe architectures and

establish metrics for its functional performance, but without compromising details

about connectivity, performance, and functional accounting. The approach is

interesting as an abstract theoretical formalism but limited when it comes to the

applicability for the ISoS domain, considering the lack of finer-grained constructors.

Modularity in computer science and engineering is mainly concerned with the

organization of computing code. Modularity has been focused on code complexity,

deal with concurrency and accommodate uncertainties [13]. A mapping for the

design of complex engineering systems named Design Structure Matrix (DSM) in

[13] is proposed and demonstrated in the case of a computer components composite.

Nevertheless, despite the discussion of the value of modularity as an encouraging

force for innovation and a market new business dynamic, based on the experience

2.2 Open Modularity Frameworks

33

with IBM and the changes in the market during the eighties, the conclusions about

the impacts of adopting modularity are limited in evidencing advantages.

2.2.1 SOA paradigm for modularity

Modularity has been a long-standing research topic. In [90], a modular systems

theory is proposed for the SOA paradigm where the authors base their conclusion on

an empirical study to argue for the need to “Implementing new, dedicated decision-

making bodies for SOA hampers organizations in achieving higher degrees of IT

flexibility and reuse”. The authors point to the need for new decision-making bodies

and in particular for SOA. Besides the importance of the relationship between

governance and the SOA modularity, there is a need for unifying models for the

underlying technological complex distributed systems. However, most of the

research in this field does not address the multi-supplier issue. In [127] and [126], a

mathematical model for dynamics and modularity degree analysis of an elevator

system is proposed and discussed. The case of Airbus, that abandoned a proprietary

modular cabinet from Honeywell, replacing it by the open ARINC 600 under the

open Integrated Modular Avionics (IMA), an open modularity specification that was

applied in the design of the A380 airplane, is discussed in [24]. It is quite interesting

that the main motivations are to guarantee alternative suppliers for the same

components and the cost reduction comes as a side-effect. Also interesting is the fact

the Integrated Modular Avionics (IMA) open architecture promoted by Honeywell,

a supplier of proprietary components.

Despite the efforts from research and contributions from the users’ community,

we are still missing a model to cope with the growing complexity of integrated

Isystems. The more recent micro-services movement, which was initiated around

2013 and adopted as a scientific research endeavor, the strategy considered seems to

differ in terms of complexity from the service orientation research. A first reference

to “Micro Services” is discussed by [115] to describe the author’s experience about

developing a large complex system. The approach to the problem domain and the

structuration of the capabilities are based on micro-services to cope with millions of

users, billions of transactions, and performance, fault tolerance, (re)configurability,

portability, and maintainability and conditioning the structuration of a large

development team. The emergent microservices topic has gained a growing research

interest, chiefly associated with cloud computing [40], [184], [12] or the

decomposition of monolithic systems into independent parts [114], [96], [97].

Nevertheless, the novel perspective of Microservices is not that different from the

long-running research towards a scientific foundation on what is being referred to as

services science and engineering [88].


34

The service model underlies our proposed ISoS framework. The CES elements

are composites of services that are coupled with peer Isystem’ elements, through an

adaptive mechanism. This makes it possible to implement services based on different

technologies.

2.3 Web Technology Facilitators

To balance the discussion, an understanding of the underlying complex assortment

of informatics technology landscapes is important, and in particular the role of web

technologies in creating new areas such as the Web Engineering [125]. The web

service concept emerged from HTTP-based programmatic access to functionalities

under the Remote Procedures Call (RPC) paradigm, expressed in the Web Service

Definition Language (WSDL), XML language and Simple Object Access Protocol

(SOAP), formulated by the World Wide Web (W3C) Consortium [73]. The RPC

concept had at the time several implementations, like the standardized ONC-RPC by

request for comment RFC-5531 and the Distributed Computing Environment (DCE)

RPC. While an important jump from the previous low-level TCP/UDP socket

messaging interactions with the advantage of abstracting low-level messaging

mechanisms, the approach turned out to be insufficient. While it made possible

reusing a higher-level language function/procedure call paradigm, and the approach

is important, it is not enough as a modularity framework. However, there had been

an important paradigm change, brought by the service orientation philosophy; it

moved the discussion to a scientific boundary closer to the business level.

Nevertheless, it is interesting to note that as far as the complexity of Isystems is

concerned, the step from the classic RPC to the more recent Web Service is not that

different. Differences are in the implementation approach and interface language.

2.3.1 Interface languages

Approaches like the ISO Interface Definition Language (IDL) associated with the

Object Management Group OMG6’s Common Object Request Broker (CORBA)

normalization dynamics promoting distributed object-level interoperability [199]

have been substituted (complemented) by the web service paradigm. The W3C7 Web

Services Description Language (WSDL) and the adoption of Web Application

6 Object Management Group, an important informatics centred standardization body

7 World Wide Web Consortium (W3C)

2.3 Web Technology Facilitators

35

Description Language (WADL) [56], turned out to be a crucial contribution to

interoperability. Substantial research efforts have been made to bring the web from

data content-centric to a distributed pervasive and loosely coupled computing

infrastructure, e.g., the proposal for the Web Service Modeling Framework (WSMF)

as a conceptual model able to describe and develop services and complex

compositions under decoupling and scalable mediation principles [53]. Figure 7

depicts an interesting synthesis showing a trend for a more ambitious goal of having

intelligent web services as an evolution from the static web to the semantic web.

Nevertheless, and after a decade, the gap between such theoretical models and

the real world proved to be much larger. Interface languages need to be mapped to

implementations as composites of elements connecting interdependent services. The

Service Component Architecture (SCA), an OASIS8 standard, was promoted by the

industry as a promising modular framework [181]. However, the same framework is

years later questioned by the same industry, arguing that the standard is restricted to

SOAP web services and is not prepared to cope with the new RESTful protocol [93].

The discussed composition of services based on coordination languages like the Web

Services Flow Language (WSFL) proposed by IBM in 2001, which would go on to

be the Business Process Execution Language (BPEL), still lacks robust theories and

models able to effectively contribute to an intra and inter-organization systems

integration based on an orchestrated coordination.

Figure 7 – A Foreseen trend for Intelligent Web Services from [53] and [113]

In spite of the many models/frameworks that have been formulated, e.g.,

CORBA/ORB [199], and JINI [192], and OSGi [124], [143] there is a need for

convergence in the era of web technologies, not only about underlying constructive

8 Organization for the Advancement of Structured Information Standards


36

frameworks but also the need for a unification of the development culture. However,

the complexity to establish a “generic enough” distributed components’ structure has

motivated many research initiatives. The proposal of a remote batch invocation

(RBI) supported by the RBI-OSGi framework is presented as having advantages over

message-oriented middleware (MOM), sockets and synchronous and asynchronous

OSGi remote services (ROSGi) evaluated against performance, expressiveness,

reliability and cost-performance ratio [102]. While addressing specific services: 1)

definition of words; 2) list of word’s synonyms; and 3) spelling suggestions for

misspelled words based on Apache Lucene search services [103], the research is a

demonstration of the complexity to establish a unified framework. In another work

of the same author, a similar strategy is applied to the search-based “DNA Hound”

on three-tier R-OSGi distributed components to support a criminal investigation

[101]. This and other approaches specialized in answering specific application

domains and requirements need a generic framework for composites of distributed

components. The Apache CXF-DOSGi offers a topology manager exporting OSGi

services with annotations for different remoting technologies such as SOAP-based

(JAX-WS) or REST (JAX-RS) web services [10]. However, the OSGi Remote

Services specification does not support dynamic adaptation for other remote

technologies than those already supported by the standard.

Diversity of the adopted de facto technology in current products and standardization,

which makes it challenging to establish a unified technology landscape, has

motivated our proposed design of a technology-adaptive-framework based on the

Cooperation Enabled Services (CES) model.

2.4 Open Reference Architectures and Substitutability

The systems integration research is addressed from different points of view: business

management, informatics (computer science and engineering), and electronic and

telecommunication disciplines. While our focus is on open (distributed) computing

infrastructures, other significant multidisciplinary contributions consider the

construction of such open systems as a challenging endeavor from the processes

perspective [37]. One important point related to our research work is the

identification of the need for multidisciplinary systems engineering by studying and

understanding the systems in the context of a system of systems arrangements arising

from the emergent behaviors not observable when considered in isolation. Being

central to our research, the existing contributions concerning substitutability as a


37

strategy to develop agnostic technology solutions and avoid the vendor lock-in

problem are surveyed and discussed.

2.4.1 Vendor lock-in challenges

The user-organizations, being public or private, as acquirers and users of Isystems,

are facing a crescent problem on how to govern their technology assets under a

sustainable model. They are questioning how they can ensure that the life cycle

management of their assets is under a market competition model, i.e., how can they

reduce the existing vendor lock-in dependencies [71], [140]. This establishes the

vendor-agnostic as our main research goal, making a technology landscape possible

to be sourced from competing suppliers without substitution constraints, enabling a

free choice among competing alternatives. At present, such substitution is not, in

most cases, easy or even possible. Current Isystems potentially require

customizations/configuration efforts after the acquisition, and in most cases, they

involve considerable costs. These efforts strongly depend on the specific culture of

the supplier of the acquired Isystem. Isystems such as enterprise resource planning,

customer relationship management, and supply chain management are based on

different development strategies (architecture and technologies, and parametrization

issues) depending on their supplier. Important standardization efforts, like the

business process model and notation and decision model and notation languages

from OMG, are not the only answer to avoid the need for specificities associated to

technology bindings, as one of the problems that make a substitution of a system a

complex and costly process. Existing standards do not seem to foster generating

compatible implementations (products) from competing vendors. No approaches

were found as concise strategies for the current handcrafted configuration efforts,

responding to specific bindings between models and implementation structures.

2.4.2 Reference architectures

The reference architecture as a strategy to unify approaches, often formulated from

vendor lock-in perspective, has been addressed by both the research community and

the industry in several projects and standardization efforts targeted to (re)think the

IT landscape. The FIWARE9 European initiative is an example of such effort to

promote the substitutability of the (computational) responsibility of Isystems by

assuring that the substitute completely replaces the existing system without any

additional configuration/adaptation efforts. The FIWARE initiative establishes the

9 FI-WARE: Future Internet Core Platform, project ID: 285248 funded under FP7-IC


38

Generic Enabler as a reference architecture and the reference implementation (GEri)

concepts as an external modularity strategy. The GE as a reference architecture

abstracts a specialized computational responsibility through a set of interfaces for

the cooperation with other FIWARE systems. This means that a FIWARE enabled

product shall be conforming a GEri reference implementation used in the validation

process (conformity certification) [57]. However, this initiative assumes that the

approach needs further efforts to define the complete standards suitable, in order to

realize the vision of an effective contribution for a multi-supplier framework.

The IT4IT is another effort, from the well-recognized normalization body Open

Group10 aiming at establishing “A Reference Architecture for Managing the

Business of IT” under the main motivation of working across the recognized silos

and the need for novel value chain where the substitutability is facilitated [141]. In

Figure 8 below, the reference architecture levels are depicted.

Figure 8 – IT4IT Reference Architecture Levels [141]

However, even if vendor-agnostic is declared as an important concern, in IT4IT

Reference Architecture it is assumed that beyond level 3, the approaches are vendor-

specific.

This and other efforts demonstrate a crescent concern about the lock-in problem

and the related substitutability concept. They represent strategies to reduce cross-

border silos, related risks, and added costs moderation difficulties (to coordinate). At

least for critical systems, there is a trend to adopt monolithic solutions under a unique

responsibility from a single supplier as a strategy to guarantee minimal risks. This

means that such complexity can only be overcome if the life cycle management of

10 The Open Group, https://www.opengroup.org/


39

integrated systems (applications) is well established, particularly for the inception

and development phases.

2.4.3 Substitutability support

The lock-in also has origins from the assortment of languages, development

frameworks, and paradigms. They are one main reason for the need for common

methodologies, tools and resources able to cope with the required holistic (systemic)

approaches. When considering the two-technology specific main lines, adopted by

Microsoft (.NET, WCF, C#, etc.) and the Java and open-source world (RMI, OSGi,

Java, etc.), there is a consensus about the advantages (fewer risks) to adopt the

unified Microsoft culture; the discussion of the migration of the municipality of

Munich from Microsoft to open source including Linux, the LiMux project, is an

interesting discussion about technology risks [177]. For Microsoft technology, there

are several potential suppliers offering development services certified under this

development and execution environments culture (proprietary). For the open-source

Java world, the situation is different; the adoption of a single (unique) development

and process cultures is of high risk. The open-source world with such diversity of

paradigms presents a higher supplier substitution risk because the new contracted

company needs extra time to understand the assets and the potential investments

required to move to its own development culture. This has led to situations where re-

utilization of existing assets is not possible or at least, is not of the interests of the

new subcontracted development cultures.

This situation can be to a large extent reduced if adopting certified competencies

on proprietary technology landscapes (Microsoft, SAP, TIBCO, Oracle, Cisco, and

many other proprietary cultures). When the strategy is to adopt open source and open

specifications not clearly led by a unique technology supplier, it becomes more

difficult to find competing companies able to support and evolve assets in such open

worlds. The apparent easier path following recognized market leaderships (brands)

leads to the vendor lock-in scenario that is understood as an obstacle to sustainable

innovation processes. Therefore, given the advantage of adopting open

specifications and open source initiatives, the problem is how to get an agnostic

framework for the required informatics systems composite.

There are several integrated development environments (Eclipse, NetBeans,

IntelliJ, among others), code generation and dependencies management tools

(Maven, Ivy, Grape, Gradle, Buildr, STB, Leiningen, etc.), issues and project

management tools (Redmine, Bugzilla, Mantis, Trac, ProjectLibre, LibrePlan,

OpenProject, MyCollab, Odoo, etc.) and well-known proprietary tools like the suite

offered by Atlassian. This diversity renders the potential advantages from adopting


40

open source dynamics a risk to generate vendor dependencies, potentially worse than

those associated with proprietary cultures. The mentioned discussion on the LiMux

project states that “vendor-independent release management should be guaranteed

with a transparency of IT costs” and interoperability are identified as major risks

[177]. Furthermore, for large end-organizations, contracting innovative start-ups is

associated with a potential risk of adopting fashion technologies, development

paradigms, and methodologies. The lack of vendor-independent standards, also

known as Open Standards, also impacts the contributions from start-ups, as

discussed in [68] classified as “High uncertainty and rapid evolution are the two key

characteristics for startups”. Such risks constrain the development of consistent

integration strategies for complex Isystems, considering that potential competing

suppliers tend to adopt their own development culture.

Concise scientific models and standards are therefore needed to establish such

a required open common culture for the development and life cycle management of

the complex integrated system of systems, establishing a common informatics

engineering culture. By informatics engineering culture, we mean the establishment

of standard technology, procedures, methodologies, tools, and a modularity

framework, making specific development easier to be managed by competing

suppliers. Such a convergence is expected to be accelerated and pulled by the end-

organizations, driven by their need for competitive informatics systems supplying

markets. Wherever possible, the convergence shall be based on standard products

and processes, at least for the specialized Isystem infrastructure (Radars, Road Side

Units, things, controllers, etc.). However, for higher-level back-office and enterprise

Isystems, the efforts to converge to standards are commonly not enough to

completely answer the evolving requirements. This has motivated the development

of common platforms like the COMPASS project that proposed a collaborative

integrated development environment (IDE) [36]. The proposed COMPASS toolset

is based on a triangular approach, which in turn is based on the Systems Modelling

Language (SysML), a profile of the Unified Modelling Language (UML) generating

a COMPASS Modelling Language implemented by the Artisan product, the Java-

based COMPASS Overture tool [110], and the runtime tester (RT-Tester) for

automation test tasks. While arguing that to open SoS is a concise contribution, the

adoption of the proprietary Artisan Studio from Atego raises the question of

openness of the approach. The concern already exists from user-organizations, as

demonstrated by the MOSA initiative. The modular open systems approach

(MOSA), a program of the US Department of Defense, is grounded on five

principles: i) establishment of an enabling environment, ii) employment of a modular

design, iii) designation of key interfaces, iv) usage of open standards, and v)

verification of compliance. This is a strategy for a unified contractual framework in


41

an open life cycle management of system of systems (complex warfighting systems)

[167].

Recent theoretical works about component substitutability consider a dynamic

reconfiguration of components by adjusting capabilities of the components to answer

the changes of the requirement. The adjustments are based on software components’

level and structured on primitive operations like instantiation, destruction, addition,

removal, binding, unbinding, starting, stopping, and parameters’ adaptation [109].

Nevertheless, while important for a scientific foundation of a system of systems, a

practical application is only viable if a unified culture is developed to accommodate

such diversity of contributions for the development of reliable complex Isystem of

systems.

The development of reference models and reference implementations

associated to an adaptive technology framework is of paramount importance to

achieve substitutability. Our ISoS approach goes beyond the discussed contributions,

by proposing an adaptive coupling approach that aims to facilitate the adoption of

existing products with a minor impact on existing implementations.

2.5 Cyber-physical Systems and Microservices

An additional important aspect is how cyber-physical systems integrate with

Isystems since critical systems require complex coordination mechanisms making

them reliable, as discussed, which is a long-researched concern [117]. As depicted

in Figure 9, the evolution from Embedded Computer Systems into Internet of Things,

Data, and Services shows a growing complexity of systems [128]. We might also see

the evolution in the other way around and identify the cyber-physical systems

abstracting the physical world by presenting a service interface or a suite of

interfaces if accessed from different perspectives (e.g., functional or data access and

monitoring interfaces).


42

Figure 9 - Evolution from ECS to the Internet of Things, Data, and Services [128]

The Smart City system of systems is certainly one example of paramount

complexity considering that it has to integrate with other systems from the city

technology landscape as suggested by the general requirements in [133] “…harness

Information and Communication Technologies and Knowledge Infrastructures for

economic regeneration, social cohesion, better city administration, and

infrastructure management”.

The trend for such holistic challenges, e.g. thinking on a Smart City

operationalized by a complex Isystem, has apparently motivated the microservice

concept that has been emerging as an interesting market dynamic “Microservices is

an architectural style in which large, complex software applications are composed

of one or more smaller services” [40]. An aspect worthy of note is that the proposal

value comes from a generalized industry adoption apparently motivated by a simple

realization of the service pattern. While the implementation originated in the

scientific community, which proposed the concept of the Representational State

Transfer (REST) architectural pattern based on the HTTP methods [55], its

simplicity and need for the emergent Cloud computing industry established an

adoption boom powered by several frameworks and tools. Despite the value brought

by REST in [96], implementation difficulties confronted by a set of dividends which

resulted from adopting microservices are presented and discussed. The suggested

dividends are: “i) the permissionless innovation (facilitate the development of

innovative services), ii) enable failure (failure can be confined to a few services), iii)

disrupt trust (tends to limit the number of required social relations, shorter


43

development team sizes), iv) you build it you own it (isolate ownership and

responsibility), v) accelerate deprecation (new versions of a service might coexist to

a smooth and safe migration), vi) centralized metadata (data persistence behind

API11), vii) concentrate the pain (concentrate governance and organization’s

security and compliance needs in a few services), and viii) test differently (clearer

definition of ownership)”. These dividends are helpful to understand the trend

suggested by microservices, in general terms not much different from the service-

oriented (SOA) paradigm. In [96], a set of misinterpretations arising from the

adoption of microservices is presented: “i) different services do coordinated

deployments: ii) client libraries are shipped; iii) a change in one service has

unexpected consequences or requires a change in other services; iv) services share

a persistence store; v) persistence tier can’t be changed without affecting others; vi)

engineers need intimate knowledge of the designs and schemas of other teams’

services: vii) compliance controls exist that apply uniformly to all services; viii) the

infrastructure isn’t programmable; ix) one-click deployments and rollbacks are not

possible”. These statements reinforce the need for open models able to establish a

sounded strategy for coherent management of such complex graph of heterogeneous

and distributed entities. There is a need for new models governing such coherent

community of loosely coupled services to be managed by a unique infrastructural

entity assuming its coordination responsibility. However, such central coordination

contributes to establishing dependencies, as discussed in [184] by suggesting

configuration management for self-management and self-healing, and orchestration

to instantiate atomic services. The proposed isolation and orchestrated deployment

of composites seem interesting, but its focus is exclusively centered on Cloud

systems and the reality made of services from multiple suppliers seems not a solid

contribution for the complex agnostic Isystem of systems.

In [114] a framework is proposed to extract microservices from the monolithic

enterprise, based on the experience reported in [172] related to the modularization

of a large-scale business application for the banking sector. The migration of a part

of a large codebase (“modularization of a monolith banking application from

late’90s; a bank’s with about 100 installations across more than 50 countries; the

application grew from 2.5 million to 25 million lines of code (LOC); 10 mainline

releases and supported by several hundred engineers”) adopted a modularization

strategy based on domains (Loan, Trade Finance), made of sub-modules with API

and internal functions. The domain has a Provided Interface (PI) and a Required

11 API – Application Programming Interface


44

Interface (RI) in addition to function calls, internal to domain functions and boundary

RI/PI function calls.

The reported migration process required nearly two years, or 520 person-days,

to design and 2,100 person-days for coding and preliminary testing, and carrying out

the design and modularization of 7 Million Lines of Code (LOC) representing about

56% of the 12.5 million LOC, 50% of the total migration, [172]. This example

highlights an important open research question: how to establish a concise

modularity approach to the complex enterprise information systems in the upcoming

total integration era?

The microservices strategy proposed in [114] seems interesting for making

dependencies loose coupled, but it does not make clear how to be applied to agnostic

systems made of microservices. A strategy like the one presented and discussed in

[172] requires more than a simplified business validation case and a clear solution to

evolve from a monolithic enterprise informatics system to compositions of

microservices. It is quite interesting to see a crescent adherence to the new

microservices trend pushed mainly by the industry when confronting the long efforts

on grounding a service-oriented approach for the development of informatics

systems. The research seems to be in a prospective phase, as it is the case of the

proposed eight steps “S1: Learning of Scenarios, Load Profiles, and Constraints;

S2: Hybrid Analysis; S3: Specification of Modernization Paths; S4: Generation of

Future State Models; S5: Generation of Performance Models; S6: Performance

Simulation; S7: Analysis of Simulation Results; and S8: Implementation and

Merging” in [97], as an approach to incrementally modernize the transactional

monolithic enterprise systems towards microservices, which seem to lack a clear

strategy for agnostic informatics systems. No evidence was found to make

microservices cope with existing (legacy) and new paradigms, establishing a vast

array of technology implementations in complex multivendor distributed technology

composites.

The structure of such microservices under market (distinct products)

responsibility remains an open question. If we think about the organizations’

informatics technology landscape as a set of systems composed of microservices,

there is a need for some structured pattern grouping of such microservices by

different suppliers (marker/contractual responsibility). Those groups of

microservices are developed and maintained by different cultures, which can lead to

a complex system of systems difficult to manage and evolve (in our proposed

terminology, Isystem of systems – ISoS). Such difficulty is corroborated by the


45

sentence “…one of the main problems of developing such highly interoperable

systems is the lack of understanding between various development groups” from

[188], meaning that a scientifically founded model framing the microservices

concept is still missing. A recent study about software architectures in large-scale

distributed projects at Ericsson confirms the complexity of evolving to microservices

[21]. The legacy code and the distributed organization with development centers

spread across different countries are discussed, but the complexity to manage and

evolve a large volume of code emerges as the main reason for an adaptive open

modularity framework.

Our proposed ISoS framework contributes and answers to many of the questions

raised in microservices research, where the service CES element is comparable to a

microservice. Furthermore, CES offers the capability to model an entire cyber-

physical system, thus establishing an adaptive bridge between the pure computing

elements and the hybrid or cyber-physical elements.

2.6 Integration of Enterprise Informatics Systems

The crescent need for a total Enterprise Information Systems integration has received

several contributions for the establishment of founded computational abstractions.

The service concept has been for long recurrently associated with the establishment

of atomic computational responsibilities. However, the question is where to position

the integration concept and its relation to legacy monolithic systems? The next

subchapters address both integration and modularity strategies towards open and

integrated enterprise informatics systems.

2.6.1 Integration strategies

The integration of informatics systems is associated with establishing links among

“isolated” independent managed systems (system of systems according to our

definition). The enterprise systems are commonly associated with organizations’

supporting facilities where the Enterprise Resource Planning (ERP) plays a central

role in other enterprise systems as a specific type of informatics system [78]. In

recent research, a web-based framework for the rapid integration of enterprise

applications is suggested as a concise approach [104]. In this research, the enterprise

application semantically unifies the enterprise system as a type of informatics

system. The web-based framework grounds on the presentation widget concept and

mash-up for a composite of web pages as a “mechanisms to get not only a tight

coupling between functions of the same application but also to couple these functions


46

with others of another application”. Nevertheless, neither the used reference

composition tools like Yahoo PIPES and Microsoft POPFLY exist today, nor the

EzWeb enterprise mashup presented and discussed in [178] succeeded as an

integration strategy. The mashup is later developed by the European FAST project

to address cross-organizational collaboration, answering to Business to Business

(B2B) integration needs [176] in the Cloud computing landscape. However, the

FAST project even offering interesting contributions from an SOA adopted

approach, seems to be focused on the manufacturing web-based application [81], not

addressing directly our research questions.

The SOA as an approach to Informatic systems integration is presented in [166]

as a strategy that “offers positive benefits such as language-neutral integration,

component reuse, organizational agility, and the ability to leverage past investment

in existing systems”. The author makes a comparison with what happened during the

seventies upon the introduction of practical, inexpensive, and ubiquitous integrated

circuits (ICs). Nevertheless, despite the existing valuable technologies to support

services development and deployment, suggesting that “(…) registries can detail the

ensemble of IT services that an organization will maintain a portfolio” does not seem

clear. The research is related to systems integration. The functional and business

aspects are commonly addressed through the business process concept as an

integration strategy [89], [63], in some cases considering the business to business

(B2B) dimension [18]. These research threads are associated with the consolidation

of a modeling approach to processes definition, simulation, and execution. The latter

is commonly associated with business processes re-engineering (BPR) towards

performance improvements. The business process management system is a strategic

technological perspective as the element responsible for the implementation or

execution of the defined business models. In [46], this symbiosis between processes

and technology is explored with the assumption that the recurrent difficulty

associated with the generalized adoption of the business process paradigm is related

to the lack of a technology strategy.

In more recent approaches to integration, the challenges consider the reduction

of the intervention of technical competencies by offering executable models that help

to keep them up-to-date. The formulation in [175] is based on the adoption of the

type-based specification of the goal (of a process) with a technical implementation

based on a computational object, the code. This research work doesn’t seem to

contribute to reducing the complexity of the gap between processes and technology.

However, it helped to develop theories for the description and analysis of both

models and software systems commonly demonstrated through simple factorial or

sorting examples. References to valuable modeling standards are not included, e.g.,


47

the Business Process Modeling and Notation (BPMN) standard, among other

languages and mechanisms recognized as key for the discussed research [132].

2.6.2 Modularity abstraction strategies

The recognized and practiced advantages of modularity led [65] to formulate the

following research questions: “i) Are the stated benefits exclusive properties of

modular designs?, ii) Do these properties follow any recognizable patterns? iii) Are

these properties universally predictable?, iv) Are these inherent natural properties?,

and v) Do mathematical methods support modular construction and optimization?”.

The author states that “modularity is an architecture strategy that is well understood,

but its underlying science is not revealed or characterized”, although systems

engineering practice has for long been based on modularity principles. The author

defines the concept of integration probability as a quantification of the modular

fitness function that can range between 0 and 100%. The Modular Architecture

Functional Distribution (MAFD) = FArchMAFD is defined as:

𝐹𝐴𝑟𝑐ℎ𝑀𝐴𝐹𝐷 = (𝐹𝑑𝑣𝑠𝑒 + 𝑉𝐴𝑅 (𝐹𝑟𝑒𝑝) (∗ 𝐴𝑉𝐺 (𝐹𝑓𝑖𝑡)) / 𝑁 (𝑓𝑢𝑛𝑐𝑡𝑖𝑜𝑛𝑠)

Fdvse is a measure of the diversity among modules, Frep the replication and N

functions is the highest number of modules in the architecture. Nevertheless, as the

author claims, the approach proved to be a powerful tool for hierarchical

architectures when applied to embedded systems in aeronautics systems. Its

application to the intra-organization or inter-organization domains is still not

covering many other dimensions, e.g., the establishment of a standard (open)

semantics framework for a division of responsibilities. In [126], modularity and

interface management of product architectures for an elevator are proposed and

discussed based on the adoption of differential equations. By stating that “analysis

done in this paper merely provides an introduction as to how the dynamics of an

elevator system in terms of modularity at the product architecture level can be

analyzed”, the author is hinting at the fact that the approach is difficult to be

implemented in the enterprise informatics systems domain. In fact, these and other

approaches to establish mathematical models for complex composites do not capture

the uncertainty resulting from the lack of well-established modularity patterns able

to guide their construction. The research in enterprise architecture has been tackling

approaches researching a consensual ontology of concepts and relationships among

them. The goal is to establish a unified common language for the involved

stakeholders from architects, engineers, and users.

In all these approaches, one main challenge is to bring the enterprise informatics

systems an understanding of a common language. Such a common language is

similar to the existing for the construction sector that maps modularity and


48

processual issues. The models proposed for the integration of enterprise Isystem are

not mathematically but empirically verified, based on real operation [80]. The

authors validate the proposed framework for a simple system of the DARPA12

System F6 program based on the proposed M+ operators to determine the “optimal

level of modularity for a given functionality of a system and under a certain profile

of the environment”. The framework worked for architectures based on pre-

established modules and constrained domain rules. Nevertheless, such an approach

to the organizations (intra or networked) coping with a system of systems seems

complex to adopt, considering there are no standard reference guidelines, and those

existing are partial.

Other research works on modularity have led to languages able to model the

problem domain and establish a solid bridge to the execution perspective. Some

researchers from systems engineering consider a closed-loop while in enterprise

information systems, we almost deal with open loops. It means that the models are

not considered for the execution phase but are instead used to help (to guide and

document) the development of the executive system (system of systems). As an

example, around 2002, Dori [44] formulated the Object-Process Methodology

(OPM) motivated by the need for a precise specification for artificial systems

through their entire life cycle. The research is focused on industrial systems for the

aeronautics domain and it is founded on shared concerns about enterprise Isystems.

The precise specification, analysis, design, and implementation of such artificial

systems are becoming ever more complex, and in the case of enterprise systems with

the need for higher integration levels. This research is aligned with other efforts

towards a recognized need for unified tools merging into a common integrated

approach, the functions, the structure, and the behavior of systems. In [92] a

“declarative and executable representation of control information systems helps to

improve information management by managing a variety of information models with

improved readability and reusability”, while in the manufacturing systems

integration, the question is how to approach the modeling and execution phases. In

more recent works, the question remains open and, from the evaluated research, no

other proposal was found addressing an agnostic strategy for the Isystem of systems

at both intra and inter-organization domains.

Dealing with the complexity of emerging software systems suggests the

adoption of a modular strategy. However, the existing approaches, e.g. centralized

12 DARPA – USA Defence Advanced Research Projects Agency


49

monolithic integration proposals, do not effectively contribute to technology

agnostic solutions. Our proposed ISoS framework, while grounded on the service

paradigm, offers an adaptive integration strategy, able to support multi-supplier

approaches in the organization’s technology landscape.

2.7 Integration of Isystem in Collaborative Networks

The system of systems concept has gained more attention with the growing

complexity resulting from the need for total elements integration to support the

emergent trend for a generalized collaborative business. In collaborative business,

organizations’ borders are blurred by dependencies among Isystems operationalizing

data interchanges through (adapting) drivers based on proprietary formats and

communication protocols creating complex networks of system of systems. Such

collaborative dynamics can be seen in almost all application domains. However, the

emerging complexity in a number of application areas, such as the transport and

logistics have deserved significant research efforts from complementary scientific

areas (technological, business, logistics and social sciences).

As an example of such complex applications a technological architecture was

required for managing interactions among organizations, for which we have

proposed and discussed the Collaborative Logistics Framework for port logistics

chain (PLC), is proposed and discussed in [8]. Our proposed framework supports the

management of port logistics governance, the logistics management platform

system, and the logistics operations model as a specific composite of elements

managing the collaborations. The operationalization suggests the need for

standardization of business documents and an electronic platform connecting the

multiple systems provided by the participating stakeholders. However, this need

naturally involves the management of a huge number of business and coordination

messages, adopting various formats (GS1, EDIFACT, DATEX, …) exchanged by a

heterogeneous (with different technological systems) group of logistics and transport

stakeholders. Furthermore, customs and other government agencies are required to

be efficient in the enforcement and authorization processes to make the overall

multimodal and cross borders transport process reliable and efficient. According to

the European Port Community Systems Association (EPCSA), the Port Community

System (PCS) is “pivotal in the Single Window concept and will reduce duplication

of data input through the efficient electronic exchange of information” and “a

strategy to aggregate, optimize, orchestrate, secure supply chain business processes

for stakeholders enabling customs to focus on high-risk cargo.” The multimodal

perspective requires a convergence and collaboration of maritime, railways, road and

air transport facilities and stakeholders with their standards and normalization


50

initiatives. Multiple application domains require a common informatics systems

strategy. Such common technology strategy shall be independent of specific needs

(or agreements) on business message formats and a specific intra-organization

Isystems (specific computational responsibilities) participating in the collaborative

processes.

The application domain that mainly founded this research work, the Intelligent

Transport Systems (ITS), also shows a fast evolution for the adoption of

collaborative businesses. Initially focused on the application of Information and

Communication Technologies to the road infrastructures, ITS is moving towards a

multimodal approach and specialized areas as freight-ITS and passenger-ITS, are

being integrated to offer advanced goods transport and mobility services [67]. To

address the crescent complexity associated with such a network of stakeholders, in

[18], an Enterprise Interoperability Ontology (ENIO) is proposed to facilitate the

integration of business processes in such networked collaborations. The authors

discuss key interaction based on a set (non-internal) of web services with operations,

namely: i) place order (Point of Sale - POS retail), ii) add new order (corporate ERP),

iii) update customer order record (corporate Customer Relationship Management -

CRM), and iv) update customer loyalty (POS retail) enhanced with semantic and

syntactic descriptions. Nevertheless, the dependency created by the proposed

approach, considering that on both sides there are complex enterprise informatics

systems with different lifecycle management policies and procedures, makes failures

difficult to identify and resolve. Such an approach has enhanced dynamic

adaptability capabilities but lacks a loose connection strategy (through a reliable

intermediate system) able to reduce the possibility of failures for the critical

collaborative business processes.

These complex dependencies need to be structured in such a way that the

collaborative business processes and the underlying involved Isystems can be

managed sustainably. One important contribution to a high-level abstraction of such

complex network is the ARCON reference model for collaborative networks, which

is based on three main aspects: i) lifecycle management, ii) environmental

perspectives both endogenous and exogenous, and iii) the intent of different

modeling abstractions, as developed by the ECOLEAD project [28], [29].

Nevertheless, for partners to integrate such networks, they must adapt their internal

systems to access the offered services (proprietary APIs). Disparate internal

organizations’ Isystems, as depicted in Figure 10, need to be connected through

specialized electronic data interchange software managing specific collaboration

contexts like UN/EDIFACT for ordering and invoicing electronic messages,

DATEX traffic information messages [119], SWIFT banking messages, etc.

2.7 Integration of Isystem in Collaborative Networks

51

Figure 10 – Prevailing interactions infrastructure for the fast-emergent

collaborations

The research addressing networks of organizations as extended organizational

systems have been studied and initially associated with the extended enterprise

concept [22]. It establishes an answer to a trend of innovative manufacturing

enterprises to evolve towards “customer-driven manufacturing business systems”

that motivated the authors to propose that “manufacturing research must now place

greater emphasis on total manufacturing business systems development”. The

extended enterprise evolved into the virtual enterprise concept, and in [121], virtual

industrial enterprises are discussed as cooperative systems. The concepts of internal

module representing the company’s information and enterprise technology systems

and the cooperation layer responsible for the management of the interconnection are

also presented and discussed. Other works have contributed to complementary areas

like research on intelligent agents. This work proposes an object-oriented approach

and the adoption of Belief Desire Intention (BDI) agent as a strategy to facilitate the

flexible (agile) design and implementation of enterprise systems [164]. In this paper,

the level of abstraction provided by business objects is discussed in depth showing

some limitations of the approach. Despite the many research efforts, after twenty

years, the idea of a “total business system”, the network of a federation of systems,

and the potential to add intelligent agents to manage and control such complex

network, remains an open research challenge. In research published in 2016, in [41],


52

a reference architecture of a technological platform for a process-aware inter-

organizational integration is proposed. The proposed strategy considers a number of

challenges, namely: i) the model and coordination of the proposed advanced

features: dynamic adaptation, context-awareness, advanced monitoring, and domain-

specific solutions; ii) the integration strategy is based on a classic Enterprise Service

Bus (ESB) and integration patterns, known to establish complex adaptations and

exchange management, apparently without an open strategy; iii) for inter-

organizational integration components, the strategy to accommodate different

interaction styles, agreement management, information sharing, and regulatory

compliance are not clear.

Despite the number of research works addressing collaborative issues and its

application to interleaved application domains, they lack a unifying strategy from

the informatics systems (technology) viewpoint. The efficiency of the critical

collaborative business depends on a digital intervention of customs, in this case, the

administration establishing a needed interleaving among different application

domains. It means that a collaborative network technology infrastructure needs to be

interconnected with different domains from transport, logistics, manufacturing, and

administration. The proposed ISoS facilitates the development of such a domain

context-free strategy since the integration of Isystems does not depend on a specific

business collaborative domain. As a validation case, our research developed a

specialized Enterprise Collaboration Manager (ECoM) as an example of Isystem

unifying collaborative interactions under a common management infrastructure

establishing the Enterprise Collaborative Network (ECoNet).

Current support for collaborative networks are based on specific technology

systems acting as adapters, that are deployed at each business partner to enable its

interoperation and to follow the business requirements. However, our proposed

ECoNet, and the ECoM Isystem, suggest adopting a common framework and the

approach towards single computational responsibility. We further demonstrate

application examples where business interactions among business partners occur

under a unified informatics system and with the specialized adapters that are framed

as Isystem elements.

2.8 Summary

The state-of-the-art research performed in the context of our research could not

identify the existence of any approach like our ISoS methodology, even though a

few aspects of the ISoS framework are addressed by some research works from

2.8 Summary

53

complementary perspectives. The development of informatics systems presented and

discussed in the literature focuses on supporting limited application domains with

narrow or delimited semantics (database system, operating system, distributed

system). Some of these concerns are addressed but targeted to restricted domains,

the aeronautics industry research is a paradigmatic example. In other words, the

proposed approaches commonly focus on answering few specific domain

requirements. They also follow the best practices, which limit the impact of these

approaches and reduce the risk to manage large sets of concepts and variables.

Consequently, these approaches do not demonstrate valuable contributions to the

development of agnostic, complex, large-scale informatics system of systems.

The fundamental concept of modularity, i.e. to break down complexity into

smaller manageable parts, still lacks a common holistic framework in practice,

considered as a potential strategy. Only specific industries and areas closely related

to cyber-physical layers like the complex airplane construction industry, where a

system of embedded systems (e-systems) is present, are founded on open

specifications and conformity procedures to enable a multi-supplier component

model. For the enterprise systems domain, only at the research project level

strategies were found with approaches towards clear contributions for development

of open Isystems, with the expectation to make the substitutability principle possible

[149].

The recent contribution from the Software Engineering Method and Theory

(SEMAT) initiative resulting in the new OMG’s Essence Kernel and Language for

Software Engineering Methods standard [138], aiming at establishing a software

engineering common elements shared by all development efforts and provide a

language for describing methods and practices [87], also do not directly address

ISoS. The concerns seem hard-handed to the motivation for our proposed

complementary CEDE initiative [149]. It is a complementary approach to unify a

development culture rather than a technology strategy for the development of

integrated systems.

The collaborative organization's dimension is constructed and maintained based

on specific and proprietary data interchange mechanisms. These are of course some

relevant normalization efforts developed by several industry normalization bodies,

such as the OASIS, EDIFACT, DATEX, and GS1. However, all these existing

products still need specific adapters to interoperate. One potential reason is that data

interchange standards still establish the models and semantics grounded on low-level

communication protocols and security frameworks. There is a need for a holistic

approach separating the semantics and the coordination of the exchanged data from

the underlying transport mechanisms that are common for any type of data exchange


54

and any application domain. This was in fact the main motivation for our proposed

ECoNet collaborative networks framework.

55

Chapter 3

3 Interoperability Through

Services

The concept of service and the related service-oriented architecture paradigm

emerged a few decades ago as an important abstraction mechanism for simplifying

interactions between parts of a distributed computing system. A main driving idea

for it was to support loose coupling associations among parts of a system. The aimed

objective was to design an open architecture, which simplifies interdependencies,

rendering modular solutions, vendor agnostic, and effortless to evolve. In this

chapter, following the general address of Service orientation, we describe our

developed approach for an open Electronic Toll Collection (ETC) case. The existing

legacy ETC relied on tight-coupled components developed under a single supplier.

The weaknesses of the existing ETC solution became evident when the ETC system

had to evolve to enable its extension with new offered services for payment in

parking lots and petrol stations, etc. We have researched the service-oriented

architecture for the ETC system to design our Intelligent Transport Systems

Interoperability Bus (ITSIBus). A prototype is also built to demonstrate advantages

of ITSIBus for evolving the ETC from a closed proprietary implementation to an

open architecture with parts potentially provisioned by competing suppliers.

This chapter presents and details the approach followed to formulate the design

and to implement the ITSIBus strategy. We also discuss the difficulties to validate

the proposed approach and to establish an integrated development and execution

environment able to cope with the underlying complexity. The complexity was

mostly related to the bulky number of daily transactions (measured in millions) and

the fact that the failure of any of the subsystems in a toll infrastructure is business-

critical for toll collection. Furthermore, a failure in the entry or exit gates of a parking

lot was also critical, and for which only a manual resolution process existed.

Chapter 3 Interoperability Through Services

56

This chapter is specifically dedicated to the Electronic Toll Collection (ETC)

case considering its importance for our developed ISoS research. In our development

of the ITSIBus, to which we also refer as the ISOS.0 in the thesis (first introduced in

Chapter 1), we investigated how to cope with different technologies and proprietary

implementations used in different system components. Furthermore, we deliberated

about system's openness, as it is needed for innovation. We have identified that a

strategy is needed to be established in order to regulate and streamline adherence of

different system components to the ISOS framework, while giving their suppliers

freedom to maintain their varied technologies. The chapter presents an extensive

overview of the ETC application domain, that is motivated by a fast evolution

towards intelligent and collaborative mobility and transports.

Parts of the content of this chapter is published in the following papers:

• Luis A. Osorio. Towards Vendor-Agnostic IT-System of IT-Systems with the

CEDE Platform, pages 494–505. Springer International Publishing, 2016.

• Luis A. Osorio and Luis M. Camarinha-Matos. Distributed Process Execution

in Collaborative Networks. Robot. Comput.-Integr. Manuf., 24:647–655,

October 2008.

• J. G. Silva, G. C. Marques, P. M. Jorge, A. J. Abrantes, A. L. Osorio, J. S. Gomes,

and J. C. Braga. Evaluation of an LPR-Based Toll Enforcement System on

Portuguese Motorways. In 2006 IEEE Intelligent Transportation Systems

Conference, pages 719–724, Sept 2006.

• A. Osorio, Carlos Goncalves, Paulo Araujo, Manuel Barata, J. Gomes, Gastao

Jacquet, and Rui Dias. Open Multi-Technology Service Oriented Architecture

for ITS Business Models: The ITSIBus Etoll Services. In Collaborative Networks

and Their Breeding Environments, volume 186 of IFIP International

Federation for Information Processing, pages 439,446. Springer Boston,

2005. 10.1007/0-387-29360-4_46.

• Luis Osorio, Carlos Goncalves, C. Goncalves, A. Pereira, B. Antunes,

N. Barrocas, and Antonio Amador. ITSIBUS Jini and RFID Open Service-

Oriented Architecture for Toll Management. In JavaONE - S. Francisco;

Session BOF (Birds-of-a-Feather) -9041, 2005.

• A. Luis Osorio, M. Martins Barata, Arnaldo J. Abrantes, J. Sales Gomes, and

Gastao C. Jacquet. Underlying Its Business Processes With Flexible And

Plugged Peer Systems: The Open ITS IBus Approach. In PRO-VE, pages

221,230, 2003

• A. Luis Osorio, Arnaldo J. Abrantes, Jorge C. Goncalves, Paul Araujo, J. Miguel

Machado, J. Sales Gomes, and Gastao C. Jacquet. Flexible And Plugged Peer

3.1 Electronic Toll Collection (ETC) Case

57

Systems Integration To ITS-IBUS: The Case Of EFC And LPR Systems. In

Processes and Foundations for Virtual Organizations, pages 231,240, 2003.


The Electronic Toll Collection (ETC) is one of the topics addressed by the Intelligent

Transport Systems (ITS) research and practice community. It has its origins in the

1920s with the first cars, 23 million in that decade, the first semaphore infrastructure

as a contribution to safety in 1914, and the first parking meter in 1935 [74]. The first

known reference to an electronic strategy to collect toll is in a study of William

Vickrey in 1959 for the Washington D.C. Transportation Department. The findings

advised for the adoption of tolling with variable amounts depending on the hour of

the day with a maximum to be set during rush hours as a strategy to encourage

commuters to use public transportation and maintaining congestions at acceptable

levels [47]. An onboard unit (OBU) to electronically identify the vehicle was at that

time an innovative technical solution, enabling toll collection without slowing down

traffic as it was customary with tollbooths.

Moreover, the ITS community has been addressing other topics like the

Experimental Route Guidance System (ERGS) that was developed in the DAIR

project in the 1960s [62]. The researched system concept was based on radio

communication transmission between the vehicle and roadside units and had the

participation of General Motors and Philco-Ford. In the 1980s, the increasing

number of infrastructures and vehicles moved the focus of research to the

environment, congestion, sustainability, and safety, as demonstrated by the first

known Autonomous Land Vehicle (ALV), developed in the DARPA13 project.

Another ITS target is tolling, commonly associated with the payment of construction

and exploitation costs of road infrastructures. More recently, such a costing model

was associated with motorways, i.e. fast-moving roads, with limited access and

separation of vehicles traveling in opposite directions, and usually with two or more

lanes. Nevertheless, transport policies other than payment of the required

investments for construction or exploitation have been developed for congestion

management and are related to environmental impacts [168].

A first electronic vehicle identification system was implemented in 1986, in

Aalesund, Norway, following the 58s Vickrey’ s vision and known as the first

electronic tolling system [83]. Later in 1995, a first tolling infrastructure was settled

13 The USA Defense Advanced Research Projects Agency (DARPA)


58

in Portugal associated with the Via Verde14 brand and the payment clearing company

with the same name. Despite the efforts that had been conducted by the European

Commission through a standardization mandate held in 1998 to evaluate a decade of

normalization efforts under CEN/TC 278 Committee on “Road Transport and

Traffic Telematics” [49], interoperability difficulties remained as the main obstacle

to develop integrated services. The conducted study recognized the weaknesses of

Information and Communication Technology (ICT) approaches to achieve

Interoperability among services offered by provider companies potentially involving

different countries (European case). The European mandate [49] establishes the need

for close collaboration ranging from automotive manufacturers, service and network

providers, establishing interoperability strategies at both international and regional

levels.

A fundamental issue that has been long addressed by the ITS community is the

existence of heterogeneous technologies supporting the business processes

automation, including toll management and related processes that, in cooperation,

implement services for an ITS integrated vision. Although a growing number of

standards exist and contribute to promoting informatics systems cost reduction

(inducing competition), there was a lack of a framework able to cope with the holistic

view as established by ITS challenges. The need for ITS integrated views as

discussed in [50] proposes a combination of information from systems and databases

through the standardization of interfaces between them. Similar ITS domain

concerns remain today and have been motivating substantial research efforts to find

holistic approaches for mobility, grounded on ecological, quality of life, and safety.

The research has been focused on the persons, conveying the complex technology

landscape involving multi-disciplinary and multicultural contributions transparently.

Our Intelligent Transport Systems Interoperability Bus (ITSIBus) [150]

challenged the idea laid out in 2001 to extend ITS systems to parking lots and petrol

stations that were hampered by a technology dependency. The challenge related to

the collaborative dimension which adds the need to formalize the complexity of

informatics systems.

This extended ITS is a challenging application domain with emerging new

business models based on complex partnerships among networked enterprises. Such

growing interdependencies require novel informatics technologies to the underlying

computing base. To cope with such fast-growing networked social and business

14 Via Verde is a Portuguese Company responsible for toll, parking lots, fuelling stations

and other mobility payment services. A company of the Brisa group.


59

dynamics have motivated the creation of new scientific areas to study and propose

concise models. The Collaborative Networked Organizations (CNO) have centered

research efforts on grasping the complex relationships among organizations and

offering both models and technology strategies [121]. At the same time, the Grid-

systems were a contemporary effort that has been strengthening the networked

dimension of the scientific community establishing networked facilities for multiple

scale scientific collaborations [60]. The terms Virtual Enterprise used by the CNO

community to define “a temporary alliance of enterprises that come together to

share skills and resources in order to better respond to business opportunities and

whose cooperation is supported by computer networks, challenges the way the

industrial production systems are planned and managed” [121], and Virtual

Organization used by the Grid Community to define “flexible, secure, coordinated

resource sharing among dynamic collections of individuals, institutions, and

resources” [60] share some common concerns. Both approaches encapsulate

collective endeavors which require concise models to find best practices:

• Sharing of resources and capabilities

o Making it possible to answer a challenging business issue or enabling

joint problem solving;

▪ Exploiting the trend for an “everything connected” world

• Collaborative production and services provisioning

o Putting together (coordinated) cooperation networked resources, such as

competencies, computing capabilities, storage, analytics capabilities,

specialized operational competencies and capabilities (smart city

operations management, mobility, and transports, payment,

collaborative logistics, control, analysis laboratories, special

installations like the Large Hadron Collider, etc.).

The above two dimensions suggest dividing the problem related to the

collaborative perspective in two parts:

i) The discovery of (coordinated, reliable, secure, scalable, simple to

manage, sustainable based on fair cost) shared resources and

capabilities; and

ii) The daily dynamics where people and physical or logical resources

cooperate for business, scientific and social endeavors (the business

processes both intra-organizations or inter-organization that we refer as

collaborative processes).

While adopting a holistic horizontal approach, our work focused on contributing

to the first dimension (sharing of resources and capabilities).


60

3.2 Analysis of ETC system

By challenging the extension of the ETC, also known as Electronic Fee Collection

(EFC), and adding fuel filling and parking lots access payment, Brisa established a

strategy to develop a multi-supplier informatics solution for the ETC system. The

new payment service provided the base challenging requirements that motivated the

ITSIBus case as presented in section 1.1.1. There was a need to support the inter-

organization processes lifecycle management and a need to lower infrastructure

costs. These two perspectives were the basis for the innovative technological strategy

driven by the following objectives:

1. Establish an infrastructure with open protocols and interfaces (standards), for

different (informatics or cyber-physical) systems, belonging to different

suppliers, competing with equivalent functionalities for the same business

processes;

2. Realize the integration vision of various processes, whether they are related to

internal (intra-organization) or inter-organization processes involving

organizations with different processes and technological cultures.

A fundamental issue is the establishment of a strategy to achieve an adequate

level of integration for informatics systems. Most of the enterprise architectures

assume the existence of independent Isystems as monolithic automation of business

processes limited in scope and confined to specific company areas (departments).

Consequently, each Isystem automates a set of business processes implementing

functionalities that, in many situations, are also implemented by other systems. In

Figure 11 a three-dimension viewer (3D viewer) is depicted as part of both CAD and

PDM Isystems.

Current monolithic approaches hinder the re-utilization of capabilities by more

than one Isystem. It might be valuable if the ETC accesses a Computer-Aided Design

(CAD) Isystem for the design and rendering of a three-dimension simulation of a toll

plaza as depicted in Figure 11. The difficulty in sharing service among Isystems is

an example of such limitations. For the ITS industry, this model has led to an added

difficulty to share functionalities among processes. A closed system implementing

ETC, integrating vehicle identification through the Dedicated Short Communication

(DSRC) technology, and Automatic Vehicle Classification (AVC) for vehicle

enforcement does not facilitate sharing the implemented services by other Isystems.

One proposed scenario was to give national security enforcement access to license

plate recognition events of vehicles declared as stolen making possible a just-in-time

3.2 Analysis of ETC

61

intervention of traffic police to solve the registered incident. While technically

feasible, it requires a novel structuration of the technology landscape (from cyber to

informatics parts).

Figure 11 – The monolithic enterprise applications perspective

As a strategy to overcome such lack of flexibility, we propose a fragmentation

of those monolithic Isystems, thus establishing a new Isystems’ organization based

on finer-grained units with limited/specialized (or focused) set of functionalities as

shown in Figure 12 for the lane controller.

The proposed fragmentation is not a new concept and it is comparable to the

“servitization” process coined in [187], reflecting a trend in the 1980s for added

value products through the addition of services. Fragmentation is also associated

with the growing success of web services technology as a standard formulation of

computational functions. Nevertheless, “Servitization is the innovation of

organization's capabilities and processes to better create mutual value through a

shift from selling the product to selling Product-Service Systems” [11] servitization

referring to manufacturing rather than informatics. Servitization establishes a trend

from monolithic inflexibility to service-enabled products able to better fulfill the

customers' expectations [82]. The direction for a generalized digital adoption and,

more recently, the “Industry 4.0” global vision of the Internet of Things, Internet of

Services, Cyber-Physical Systems, Smart Factories, Big Data, Cloud Computing,


62

Cyber-Security, and Autonomy face complex integration challenges. In spite of the

potential social and business benefits, the lack of a sustainable informatics

infrastructure compromises the potential value of such servitization [82] or

innovation trends. They require decreasing granularity of services and establishing

small-grained entities able to be assembled (integrated) to cope with business process

requirements under the market competing for procurement.

In our approach, however, we promote the breakdown of monolithic

applications into a set of small execution units offering specialized services to be

used in enterprise processes, i.e. a kind of technological “servitization”. Such

transformation was applied to the Electronic Toll Collection (ETC) Isystem, as

depicted in Figure 12. This breakdown is founded on adaptive integration benefits

from adopting a standardized declarative business process definition. The

standardization efforts, Business Process Modeling and Notation (BPMN) (currently

in version 2.0), and the Decision Modeling and Notation (DMN) (version 1.0) led by

the Object Management Group (OMG) have been a key contributor to a standard and

open processes automation framework. The discussion of the proposed integration

framework adds to a better understanding of the border between the proposed

technology strategies and processes domain.

Figure 12 – Disintegration process of a monolithic application/system

One main constraint facing this breakdown process was the lack of an open

architecture establishing what should be the division of responsibilities and the

answer to external and internal modularity [149]. Our research is founded on the

need to establish a modularity framework able to induce the substitutability

principle, enabling a competitive procurement. Therefore, based on the legacy ETC

AVCAVC

ImageImageDisplayDisplay

Lane

Coord.

Lane

Coord.

LPRLPR

DBMSDBMS

ETCETC

Lane Controller Lane

Controller

Disintegration

DSRCDSRC

3.2 Analysis of ETC

63

Isystem and in cooperation with two potential suppliers, Q-free15 and Kapsch16, the

Dedicated Short-Range Communication (DSRC) technology and the Road Side

Equipment (RSE), commonly identified as the Via Verde antenna, were regarded as

autonomous subsystems under external modularity. Such autonomy means that any

component of the RSE subsystems can plug to the infrastructure based on a dynamic

adaptation process. Nevertheless, for strategic reasons (costs), suppliers were not

asked to change their RSE equipment but instead to implement an adapter. The

model considers that the vehicle License Plate Recognition (LPR), the Automatic

Vehicle Classification (AVC), the Display unit for presenting the prices, from other

elements of the infrastructure are supplied as plug-and-play elements implementing

services.

3.3 Specification of ITSIBus Model

The ITSIBus (ITS Integration/Interoperability Bus) was motivated by the existing

technology dependencies, as discussed in Section 3.1. To succeed, the architecture

needs to be preceded by the reassessment of the resources and capabilities sharing

features. The new virtual payment system planned to extend the toll fee collection

infrastructure to car parking lots and petrol stations has introduced interoperability

challenges difficult to overcome with current technological frameworks. One of the

main problems is technology dependency from a single supplier. The existing

technology strategy, quality of services, and coordination mechanisms are not

compatible with the new dynamics imposed by the required collaborative business

process [158]. Therefore, the researched problems led to the adoption of a strategy,

which involved the development of the open Intelligent Transport Systems

Integration Bus (ITSIBus). It aimed to contribute to the implementation of an

advanced framework able to cope with the need for generalized cooperation among

distributed and multicultural enterprises (concessionaires, parking lots, and fuel

distribution forecourts) with their informatics or cyber-physical systems. The

ITSIBus strategy considers two main approaches: i) a bottom-up approach with

efforts to establish the concept of multiple pluggable supplier peer systems centered

on the Dedicated Short-Range Communication (DSRC) and the Automatic License

Plate Recognition (ALPR), and ii) a top-down approach focused on proposing a

distributed business processes execution and coordination infrastructure.

15 Q-free, Norwegian company supplier of ETC systems and solutions.

16 Kapsch, Austrian company supplier of ETC systems and solutions.


64

When comparing servitization to the microservices paradigm, the former

introduced three important technological/strategic constraints that shouldn’t be

discarded in the context of the latter:

i. The selection of the technological approach considered the evaluated

web services, JXTA, JINI, and other alternatives for the distributed

computational services;

ii. The potential need to induce a changing effort for the former single

technology supplier (Q-free) and the new Kapsch, with the risk to

aggravate costs rather than the expected reduction (a demonstration,

key for the maintenance of investment in research);

iii. The lack of a common environment for the deployment and running of

the services. An initial decision was made to avoid runtime library

component costs and take advantage of the open-source dynamics,

instead of the proprietary COM/DCOM/.NET environments, the Java

language and the Java Virtual Machine (JVM) execution environment

were selected.

Despite massive standardization efforts, a concise and complete strategy was

still lacking, especially when considering the adoption of an SOA approach.

Currently, just like in 2003, albeit some minor differences, the development of an

open ETC Isystem remains a challenging endeavor. Despite Q-free company already

having adopted the web technology for its RSE application layer, the web services

technology was at an early stage. However, a competitor RSE from Kapsch made

available the vehicle transactions and management functionalities (application layer)

through specific TCP and UDP ports. While a standard existed at the application

layer, only the exchanged messages (the payload) were defined, not the entire

interaction between the RSE and the lane controller. Another difficulty was related

to the selection of most appropriate programming languages, technologies,

frameworks, and execution environments, from other elements of the computational

infrastructure. In the case of the RSE, the project developed an initial evaluation of

the potential adoption of web services. However, real-time speed constraints of

vehicles crossing a lane and the introduced latencies to transactions processing on

the existing hardware showed performance problems. The number of toll

transactions a day in the Brisa’s network was about one million. Founded on the

added risks of adopting a technology with a heavy payload (XML), the JINI

framework [192], [193], was selected as an execution environment for the ETC

services. Furthermore, in a contribution to a higher-level abstraction for the ETC

services, the system concept was proposed as a container encapsulating not only the


65

core service but also complementary functionalities to manage the services lifecycle

[150].

Our approach proposed a new organization of the execution system based on

“plug-and-play” services. The proposed strategy promoted an open integration bus

based on open interfaces able to plug several different systems. This open integration

bus, which considers an open reference implementation, is aiming to contribute to a

unified pluggable infrastructure. The ITSIBus is founded on three main concepts: i)

the system as a services container; ii) a predefined set of services; and iii) the

execution container. The system concept identifies an execution container of a set of

services (the second concept) depicted in Figure 13. These services are the

implementation of functionalities grouped on a fine-grained based strategy. The third

concept is related to the standardization of the execution container, the service

definition, and deployment framework. The services plug to the ITSIBus System

following the concepts proposed by the UPnP (Universal Plug and Play) forum,

which integrates the Open Connectivity Foundation (OCF) since 2016. In addition

to the UPnP service, the service execution container embeds monitoring and security

services.

Figure 13 – The proposed execution container for the ITSIBus services

The monitoring service is an important contribution to the management of

quality of services (QoS) and the coordinating decisions for fault tolerance. The

security services are important when Web-based (Internet/remote) accesses are

required.

The UPnP characteristic facilitates the registration of the services into systems,

which are identified by service class, service provider, version and other profile


66

information. As an example, service classes in the toll arena, some under

standardization by CEN/TC 27817, were considered:

• Vehicle identification based on Dedicated Short-Range

Communication (DSRC) developed;

• Automatic Vehicle Classification (AVC);

• Display and light;

• Vision acquisition;

• License Plate Recognition (LPR);

• Lane coordination;

• Toll coordination;

We adopted a strategy that considered a (business) process represented by a

declarative language (e.g., BPEL) modeling and implementing the coordination of a

suite of services. The idea was to limit the scope of processes to the execution of

planned activities and export the services required by other processes. This way, the

end-user companies have an added flexibility to arrange their informatics resources

according to the need of their (business) process. The formulation contributed to the

re-engineering of the business processes and promoted supplier independence. This

approach helped increasing flexibility of the end-user enterprises, giving them the

possibility to freely choose services from different suppliers.

The flexibility promoted by the ITSIBus theoretical model enables the

execution of one or more systems in specific execution environments (Windows,

Linux, or Real-Time Operating System) in a virtual machine, Java or Common

Language Runtime (CLR). Execution across multiple systems can happen if, for

instance, a system needs to connect through physical interfaces to local hardware

devices (see Figure 14). In the ITSIbus model, the ETC modularity is founded on the

system concept as a container of services under a unified technological framework,

which in turn is based on JINI. Each lane has cyber-physical systems (equipment)

incorporating specialized functions managed as an ITSIBus system. A DSRC system

is a cyber-physical Road Side Equipment (RSE) responsible for interacting with

devices (radio frequency communication, sensors, actuators) to electronically

identify a vehicle. The vehicle classification system establishes toll values based on

the height of the vehicle in the first axis measured by a laser sensor, which is another

example of an RSE (the toll fee depends on a set of classes established by the height

of the first axis and the number of axes). The proposal ITSIBus model aimed to unify

17 European Standardization Committee, Technical Committee 278, Intelligent

Transport Systems (ITS)


67

the integration of toll equipment following JINI framework for the plug of services

in a local network [191].

Figure 14 – Details of the ITSIBus enabled system as a service container

The last challenge for the ITSIBus model is inherent to the cyber-physical

systems and, hence, it led to a computational model promoting isolation from the

remaining computational parts through device adapters. For instance, the RSE

suppliers can comply with standards to connect their autonomous systems, like IP

connection, serial RS-23218, current loop RS-48519, and many others.

Figure 15 shows an open ITSIBus based Electronic Toll Collection (ETC) with

four (business) process levels:

i) Lane interfacing with cyber-physical systems;

ii) The lane controller service responsible for the coordination of the

connected cyber-physical road systems;

iii) Toll plaza aggregating lanes and making possible fault tolerance

coordination; and

iv) The Central system as responsible for managing the transactions of the

tolled motorways and bridges network.

At each level, from lane to toll plaza central system, a coordination business

process manages the services under its responsibility based on a declarative

approach. Each coordination service exports a set of services that are used by a

coordination service at the upper layer.

18 Electronic Industries Association (EIA) standard

19 Technical details in Wikibooks

System

Services

DevicesExecution

Environment

System

ExecutionEnvironment

System

ITS-IBusITS-IBus

ServiceServiceServiceService

https://en.wikibooks.org/wiki/Serial_Programming/RS-485


68

The architecture reflects the hierarchy found in a real toll system. However, it

helps to isolate the different components used in toll systems (changes in specialized

process implementations do not influence the overall system). Our approach was

important as a strategy to promote the multi-vendor paradigm despite the decision

not to impose its adoption by suppliers. There was a risk of thriving costs (resulting

from the potential investments suppliers may need to move from their development

culture). The strategy to maintain the ITSIBus vision adopts a surrogate approach as

discussed in [191]. The cyber-physical systems abstract through surrogates, like

adapters, and this way preserved the adoption of the ITSIBus models. The ETC

equipment’s (DSRC, AVC, Display, LPR), as depicted in Figure 15, are abstracted

as systems holding the required services, thus establishing the ITSIBus open service

bus.

Figure 15 – General ITSIBus architecture for a toll application domain

3.4 Proof of Concept Prototype

We developed a proof of concept prototype for the ITSIBus. After an initial test of

potential technologies for the implementation of the service paradigm, the research

case as explained before adopted the JINI framework and its reference

implementation from Sun. Our case built an initial demonstration later became a

product developed by Brisa, the eTOLL system, as an example of roadside

equipment for a self-service tollbooth. Furthermore, our case developed a prototype

based on .NET technology because of the strong dependence of the Brisa company


69

on this technology. An evaluation was developed based on a System Broker playing

a bridge role between the two implementations, as shown in Figure 16.

The eTOLL incorporates an LMS system with a lane coordination service. This

service manages other systems like DSRC, AVDC, LIT, and a gate responsible for

interacting with the toll users, as depicted in Figure 16. When using this kind of lane,

the driver selects the payment method using a bank card through the Reader and

Ticket Validation Device / “Leitor e Validador de Títulos” (LIT) component or else

using cash (coins or banknotes), and in this case, using the cash input/change system.

This type of lane also includes a gate to be opened when payment goes through, also

implemented by a specialized service.

Figure 16 – Architecture for the eTOLL prototype

The ITSIBus approach helped to abstract the internal structure of the eTOLL

subsystem. The question is not whether the internal structure of the eTOLL follows

the ITSIBus structure but rather whether or not eTOLL subsystem integrates with

the toll management infrastructure. The developed prototype considered the

implementation of the eTOLL system following the ITSIBus architecture bound to

the .NET technology suit. The adoption of a different technology made possible to

challenge interoperability following the adopted system/service granularity. In the

case of the eTOLL system, the pluggability discussed at LMS level, i.e., the eTOLL

system is an autonomous system (based on .NET) that integrates to Toll Plaza

Management System (TPMS), and other JINI-based Lane Management Services

(LMS) systems. The system broker concept supported the management of

system/services developed in different technologies [147].


70

The systems/services are registered through a System Broker in an embedded

directory service. The System Broker is responsible for creating proxy services for

each relationship between services on different technologies. For different

underlying technologies, the proxy needs to know how to bridge them. Our initial

approach adopts a proxy service for route calls that maps different technologies, such

as JINI, .NET or JXTA, as suggested in [198]. However, the strategy led to some

questions related not only to introduced latencies but also to the extra complexity to

adapt services developed based on different technologies. Besides, as different

suppliers can source system/services, the mapping introduces an extra difficulty to

manage the lifecycle of such heterogeneous system elements. This drawback has

motivated a different approach to deal with heterogeneity. Instead of adopting or

bridging heterogeneous systems the proposed approach is to consider that system

elements can be heterogeneous and instead of adapters in ISoS.0, the ISoS (Isystem,

CES) strategy as presented and discussed in the next chapter, is based on a self-

adaptability of each system element to its cooperating peer. There is always an extra

effort to deal with diversity. However, the adaptation efforts are encapsulated into a

system and of the responsibility of its producer. As we will discuss in the next

chapter, our approach aims at inducing a convergence or unification of cooperation

mechanisms without imposing the unification of the adopted technology or

technologies.

A prototype of the ITSIbus framework was developed based on the JINI

framework [191]. A prototype of a workbench based on Eclipse platform was

developed to help the validation of developments based on the ITSIBus framework.

Figure 17 depicts a partial view of the wizard to guide the developer during ITSIBus

code generation. The figure shows the creation of a test client for existing ETC

services and the deployment configuration file. The main purpose was to evaluate

approaches towards model-driven development or engineering (MDD/MDE) [66].


71

Figure 17 – A view of the ITSIBus Eclipse-based workbench development

framework

The ITSIbus System is itself a JINI service aiming at managing other services

implementing specialized capabilities. The JINI Entry concept [192] models data

associated with services (meta-data) specialized as ITSIbus data elements. The Entry

abstraction supports modeling for both the System concept and for the specialized or

application domain services.

The System concept is, therefore, a type of meta-service responsible for

managing a suite of (application) services answering a specific application domain,

e.g., the services of a lane management system (LMS). As depicted in the UML

model, Figure 18, a System maintains descriptors of the instantiated services. A

service can subscribe to events from both a System (as a service) and a service

through the registerServiceHandler() method.

Figure 18 – The ITSIBus System and Service concepts


72

The System is a container of managed services that can be instantiated or

remove based on its service identification (serviced). Somehow, the System presents

some similarities to the OSGi service lifecycle management, and the dynamic

install/uninstall feature. However, instead of a generic dynamic modularity

framework, the ITSIBus System concept was targeted to establish a service

infrastructure for groups of application services under a unified execution

framework. The ITSIBus interface aimed at making simple to develop specialized

services sharing a common definition. The specific requirements like those related

to real-time and re-utilization of legacy systems can be wrapped, making them

services for the proposed framework. The validation for the tolling application

domain established specific data structures, as depicted in Figure 20.

Figure 19 – ITSIBus service specializations for the toll application

Our approach proved as a valuable strategy for the evolution of the existing

monolithic Electronic Toll Collection (ETC) solution to a multi-supplier composite.

Despite not adopted directly by suppliers, the ITSIBus introduced the service-

oriented concepts that helped to add a second supplier for the RSE subsystem. The


73

ITSIbus adopted the JINI distributed services framework [192]. The JINI framework

contributed to the simplification of the integration of system elements from different

suppliers, abstracting them by an ITSIBus service through adapters or surrogates

[191], managing interactions with the RSE equipment (vehicle identification based

on dedicated short-range 5.8GHz communication system).

Figure 20 – Event data type and specializations for the tolling application domain

Our approach has contributed to the simplification of a tolling infrastructure to

connect cyber-physical systems from different suppliers. However, the dependency

from a single technology (Java/JINI) didn´t facilitate an answer to the plug-and-play

endeavor. Existing suppliers lacked preparation for such a technology change

without extra costs, that being the reason why the strategy was to adopt the

adapter/surrogate pattern [191]. Despite the technology dependency, the

development of common interfaces for roadside specific system elements was a

valuable contribution to the move from a single to a multi-supplier technology

landscape, as discussed. Chapter 4 presents and discusses the evolution of ITSIBus,

the Informatics System of Systems (ISoS) framework, answering the multi-supplier

(or agnostic solutions) issue by adopting an adaptive, and strategy for

implementations independence.

3.5 Migration Project Application at Brisa Industry

The proposed ITSIBus was evaluated by the RSU supplier Q-free to incorporate its

RSE. The motivation seemed to be related to a price reduction pressure resulting


74

from the existence of a second RSE supplier (Kapsch). The proposal from Q-free

suggested moving some of the computational responsibilities for the lane

management system (LMS). The supplier’s strategy was to reduce the RSU

complexity, making the product cheaper.

Nevertheless, such an architectural shift would change the fault-tolerance

model. By making RSU dependent on functionalities running on the LMS, it would

lose autonomy. If the LMS fails, the RSU no more continues to collect vehicle

identification transactions, a feature common to the current RSU. Even if the fault-

tolerance could diminish by making other LMS replace the faulted one, the approach

was more complicated. It required a tight interaction between the integrator

responsible for the open ETC (Brisa) and this supplier (Q-free). The following

chapter discusses this aspect, framing the evolution from the ITSIBus models to the

CES concept [145]. The CES strategy is proposed to cope with complex interactions

among systems’ elements under a dynamic adaptation strategy.

There is another important aspect related to the open ITSIBus specification.

Experience informs that the user-organization leadership and a solid strategy to

converge to unified approaches are of paramount importance. The operational risks

establish critical difficulties in adopting a strategy towards an open system. As a

crucial process, the toll collection was under pressure to increase efficiency (reduce

toll income losses). The new supplier had to improve its RSE to comply with the

DSRC low data rate version (which used to be only available from Q-free). The

change suffered the type of problems like semantics misinterpretations of

specifications (formal or industry standards). Such distortion urges conformity

certification procedures that guarantee the substitutability of an external or

aggregated subsystem. It is also essential to precise that the constraints posed by the

adoption of two suppliers for the RSU system were not only computational but also

electrical and physical. As the RSU system from Q-free and Kapsch have different

physical formats, a standard fixing structure needed to be agreed beyond power

supplying voltage (48 and 220 volts) and different industrial plugs (parallelepiped,

cylindric). Such heterogeneity means that the integration of cyber-physical systems

in an Isystem of systems requires a multidisciplinary approach to cope with all the

expertise dimensions conditioning the global quality of a systemic approach.

3.6 Summary

We proposed the Intelligent Transport Systems Integration/Interoperability Bus

(ITSIBus) as a novel service-oriented model for an Electronic Toll Collection (ETC)

Isystem with subsystems ranging from cyber-physical to computational systems. The

3.6 Summary

75

formulation founds on the need to evolve from a monolithic closed ETC system,

dependent on a unique supplier, proved to be too expensive to evolve and to cope

with the new business model associated with the payment through the Via Verde

service contract in parking lots and fueling forecourts.

Furthermore, the perspective of Brisa moving from an exclusive motorways and

bridges toll and traffic operator to a mobility services company has motivated the

development of a strategy to enable sustainable management of the distributed

Isystem of systems ranging from cyber-physical to complex computational

responsibilities. While for the cyber-physical systems level the establishment of

loose coupling strategies is simpler than for higher system levels, e.g., business

process automation and user interface, there are a potentially large number of

possible architectural strategies in some cases guided by business interests instead

of committing to a real multi-supplier model based on a simple and costless

substitutability principle. The experience with the Road Side Unit (RSU) from Q-

free demonstrates that situations can be formulated and justified by several

arguments but also shows that it is difficult to accommodate them in an open Isystem

of systems strategy.

The complexity of the necessary programming code, in many cases with parts

in different programming languages and execution environments (operating system

or virtual machine levels), makes technology dependencies a major research

challenge, for which this thesis aims to be a relevant contribution.

77

Chapter 4

4 The Isystem of systems (ISoS)

Framework

The services ITSIBus framework [147], [157] described in Chapter 3, proved to be

a significant contribution for a shift from a closed to an open Electronic Toll

Collection (ETC). Nevertheless, even if the ITSIBus achieved independence from

the unique supplier, the fact that the ITSIBus still requires adaptors has motivated

further research to find a computational abstraction able to cope with the trend for

specific technology cultures. The initial ITSIBus infrastructure, just like grid

middleware, considers a unified technology approach and capabilities to integrate

through adapters (and application programming interfaces - API). As a contribution

towards resolving the complexity introduced by current tailored adaptation

mechanisms, ITSIBus evolved into a novel concept which we have named

Cooperation Enabled System (CES) [145]. CES aims to establish a technology

abstraction, rendering peer clients aware of technology specificities. The CES

abstraction establishes what we refer as an adaptive coupling of informatics system

(Isystem) elements and Isystems themselves. The Isystems are therefore composed

of CES elements establishing independent computational responsibilities at the

organization level under the responsibility of the IT sector, as it is commonly

referred. The technology landscape of an organization is therefore a composite of

Isystems where the Isystem0 (Isystem zero) is a coordinating meta-Isystem. The

proposed informatics system of systems (ISoS) based on Isystem, CES, and Service

models establish a convergence towards independence from specific technology and

services providers by standardizing technology and development culture [120]. The

core concept and implementation described in this chapter are also partially

published in the following papers:

Chapter 4 The Isystem of systems (ISoS) Framework

78

• A. Luis Osorio, Luis Camarinha-Matos, Hamideh Afsarmanesh, and Adam

Belloum. Towards a Mobility Payment Service based on Collaborative Open

Systems. Springer International Publishing, 2019.

• Luis Osorio, Adam Belloum, Hamideh Afsarmanesh, and Camarinha-Matos.

Agnostic Informatics System of Systems: The Open ISoS Services Framework.

Springer International Publishing, 2017.

• A. Luis Osorio. Towards Vendor-Agnostic IT-System of IT-Systems with the


• Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh. Cooperation

enabled systems for collaborative networks. Adaptation and Value Creating

Collaborative Networks, volume 362 of IFIP Advances in Information and

Communication Technology, pages 400–409. Springer Boston, 2011.

• Osorio, Carlos Goncalves, Paulo Araujo, Manuel Barata, J. Gomes, Gastao

Jacquet, and Rui Dias. Open multi-technology service-oriented architecture

for its business models: The ITSIBus eTOLL services. In Collaborative Networks

and Their Breeding Environments, volume 186 of IFIP International

Federation for Information Processing, pages 439–446. Springer Boston,

2005.

In addition to ubiquity, the upward integration has made informatics systems

increasingly complex. The modeling techniques, methodologies, development

strategies, deployment and execution environment, maintenance and evolution, and

governance are creating (un)integrated informatics technology systems that can

easily lead to vendor lock-in situations. Due to the complex relationships between

technology, informatics science and engineering on the one hand, and the

organization’s processes domain on the other hand, also identified as a gap in [123],

it is recognized that convergence towards common understanding of clear

computational responsibility borders is quite challenging. Existing approaches and

standards fail to be complete with regards to establishing a vendor-agnostic model

for the informatics technology landscape, namely free from any lock-in.

This chapter extends our previous research by proposing the ISoS as an open

informatics system of systems (ISoS) framework made of Isystem and CES

abstractions. In section 4.1, a bridge between the previous ISoS.0/ITSIBus and the

new proposed CES model is presented. A definition of the ISoS modeling elements

is provided in section 4.2, followed by a discussion about the substitutability

principle in Section 4.3. Section 4.4 discusses the relationship between ISoS

elements and process modeling paradigms and standards. Section 4.5 includes a

4.1 From ITSIBus to CES

79

validation case followed by the discussion of a strategy for an open ISoS Framework

in Section 4.6 and a summary in section 4.7.


From our design and analysis of the ITSIBus system, we learned that a common

abstraction of the diversity of existing technology frameworks is quite challenging

to achieve. Therefore, considering the risks of increasing the costs, an adaptor

/surrogate [191] was adopted, avoiding intrusiveness into component’s

implementation strategy and the need for a supplier to adopt new technologies.

Analyzing this design choice of ours it became clear that it was important to develop

a concept with the purpose of “isolating” components detail from the environment

with which they integrate. We refer to this concept as Cooperation Enabled

System/Services (CES). As a principle, CES abstraction can embed any

computational element. The S in CES [145] refers to both System and Service,

depending on the context it is used. Considering CES is an element of an Isystem,

“Services” is more appropriate, since CES is an element implementing a set of

services. The word System for CES might suggest it is a standalone artifact.

Standalone means that the CES abstraction is out of the context of an Isystem.

Therefore, CES can model any technology artifact made of software or interface with

the physical environment (e.g. cyber-physical). In the case of cyber-physical systems

without enough capabilities to be considered as a CES, a service surrogate [193] can

play this adapting role, rendering the specificities of the different protocols

(wrapping role) transparent. Figure 21 shows the example of a roadside equipment

(RSE) embedding CES mechanisms. The CES surrogate services mediate to interact

with a cyber-physical system.

The CES as a core abstraction of the ISoS framework can be used to wrap legacy

systems, thus reducing efforts for the migration from the current adapter-based

landscape to an adapterless integration. By adapterless or cooperative enabled, we

mean the formation of Isystem composites based on elements (CES elements)

prepared for the cooperation from inception [145]. The migration strategy is

grounded in the identification of existing dependencies generated by the adapter

paradigm, wrapping legacy systems, and integration servers or integration hubs

forming the legacy Enterprise Service Bus (ESB) [34]. The complex dependencies

of the ESB paradigm require a definition of new computational responsibility

boundaries for Isystem or CES abstractions. The responsibilities associated with the

ESB model, e.g.: i) providing connectivity, ii) data transformation, iii) intelligent

routing; iv) dealing with security; v) dealing with reliability; vi) service

management; vii) monitoring and logging; and viii) business activity monitoring


80

(BAM) [91], constitute a complex migration process. From a logical perspective, the

ESB paradigm was important in enabling an effective shift from the “incidental

architecture” based on point-to-point specific integration solutions, which are

difficult to maintain and evolve [34]. The dependencies among Isystem products

continue to exist as a complex web of interactions. However, with the strong frame

we have designed for ISoS, those interactions are based on the proposed CES

adaptive mechanism, making any required capability searchable through a uniform

integration mechanism.

Figure 21 – Supporting adapter-based integration of systems provided by different

suppliers

The Cooperation Enabled System/Services - CES addresses the recognized

ITSIBus limitations, namely its dependence on a specific technology. As with the

ESB paradigm, the ITSIBus adopted an exogenous integration strategy since

external adapters (integration hubs) were necessary to glue (mediate) heterogeneous

parts. With our proposed CES, the approach is slightly different since parts are able

to interact even if peer systems or elements of a peer system are developed based on

different technology frameworks. Hence, an element abstracts a set of services

accessed through a dynamic binding mechanism (Self-Awareness). Such adaptive

CES establishes an endogenous integration paradigm. We understand endogenous

integration as the approach where each subsystem or system element is located from

inception through development for cooperation. Adopting the CES model does not


81

eliminate the need for mediation between peer elements. It might happen that, like

in an exogenous integration model, a CES element plays a mediation role between

two system elements. However, this mediation role is not imposed by the adopted

technology strategy as it happens with the ESB model. With CES, any peer can adapt

to interact if it implements compatible endpoints i.e. the client to service interactions

mechanisms.

Therefore, unlike the exogenous ESB integration, the ISoS approach has the

potential to reduce lifecycle system costs, operational risks, and reduce technology

dependencies [120]. The ESB model requires an additional computational system

involving dedicated hardware, proprietary software, and specific models and meta-

models. The complexity of the integrated solutions suggests novel approaches when

it comes to using simple sensors or actuators, more recently emerging as the Internet

of Things (IoT) [25], or complex enterprise informatics systems.

Figure 21 shows the transition between the ITSIBus and the adoption of CES

elements embedding the Kapsch and Q-free roadside equipment. The ITSIBus can

logically continue to exist as a standardization effort towards the unification service

interfaces for highway tolling systems and system elements. The service execution

environment domain (SEED) is then evolved as the Isystem and the CES concepts,

where the CES elements, as autonomous artifacts, run on the execution environment

depending on the adopted technology. This change founds our planned strategy for

making the ISoS framework independent from the application domain. CES is

context-free since the proposed mechanisms to model atomic computational artifacts

do not depend on a specific application domain. As we will discuss foremost, the

application domain semantics is included in the development of reference models of

Isystems or CES under application domain standardization efforts. These efforts are

suggested to generate reference implementations used in supporting conformity

programs towards conformity certification of compliant products.

In Chapter 5, we discuss the CES element framed into the next abstract Isystem

concept and the Isystem grouped in what we define as the Informatics System of

Systems (ISoS) framework [120].

4.2 ISoS Modeling Elements – CES and Isystem

The semantics of Isystem as part of a system of systems (ISoS) technology landscape

[120] refers to the well-established logical boundary where the Cooperation Enabled

System/Services (CES) concept models the informatics systems, elements. Our

approach abstracts software engineering concerns, by entering them into system

elements through the introduction of the adaptive CES modularity. The CES


82

modularity strategy establishes the designed, developed, maintained/evolved and

dissolved atoms (system element) based on the appropriate software-centered

models and technologies. The independence/isolation of CES makes software

implementation decisions independent of the systems integration concerns. With the

proposed integration framework, requirements are mapped to cooperation

interactions between CES. The interactions occur via declared services, accessed

through services awareness endpoint, service zero (I0), also identified as a meta-

service.

The atomic CES component (Isystem element) is therefore composed of a

special service responsible for the managing of information about the implemented

services (I1, …, In) of a CES component. The Isystem composite is managed

dynamically through a coordinating CES, the CES zero (CES0) or meta-CES. The

CES0 element makes it possible to manage the incorporation of a CES that has at

least two competing suppliers. The multi-supplier aspect, while key for our definition

of open informatics system, can be loose, thus representing a partially open Isystem.

An Isystem is partially open when not all its CES elements have at least two

suppliers. In-house developed Isystems allow the removal of market dynamics

(standard products), at least where some of the CES are concerned. Such a lack of

competing products might be related to the fact that the business case does not

motivate other companies to develop and market CES products. As far as CES

development and its support for multi-suppliers are concerned, the CEDE’s [149]

unified development framework is thoroughly discussed in section 5.4.1.1.

The CES concept enables the organization’s strategy to empower the creation

of a technology ecosystem made of a composite of Isystems in an integrated and

consistent manner. Both Isystems and CES establish a thin technology-agnostic

abstraction hiding under a common and open framework, and independent of a

specific technology. The ISoS, which is composed of Isystem, CES, and Service

concepts, determines the organization’s upper technology layer as a strategy to

contribute to an open, “totally” integrated organization based on Isystems. Towards

this endeavor, the deployed Isystems need to cooperate by sharing and exchanging

data (synchronous or asynchronous), beyond other common issues like

authentication, security, quality of services, governance, and monitoring, to mention

only a few. Such “total” integration challenges under an open multi-supplier Isystem

approach establishes the concept of Isystem of systems (ISoS) [120], presented and

discussed in detail in section 4.2.2. The following section 4.2.1 presents modeling

details related to CES, Isystem, and the system of systems ISoS framework.


83

4.2.1 Cooperation Enabled System (CES)

The Collaboration Enabled System/Services (CES) concept aims to contribute to the

separation between modeling and the realization phases of system development [94].

The idea follows contributions for the model-driven development (MDD) approach

[105], [174] as an agile and adaptive mapping between requirements and execution

or operationalization aspects of a system. The proposed approach promotes a system-

centric thinking, rather than a software-centered development of the whole system.

The proposed systems thinking [94] requires an effort to generalize the system’s

implementation perspective making subsystems adaptable to a diversity of

requirements and able to support the derivation of new subsystems with the required

capabilities. The CES concept supports such flexibility, enabling a component’s

repository to support process development tools during technology bindings when

execution resources are associated to process activities [158]. Therefore, CES

addresses three main challenges:

i. Supporting a model-driven and process-oriented development of open

complex collaborative solutions as later discussed in Section 4.4;

o Mapping of functional and non-functional requirements to CES

capabilities;

o Model-based selection and evaluation of CES’s compositions;

o A hierarchy of CES generalizations/specializations definitions

to the matched requirements. A new CES or specialization of an

existing one should be a decision from a selection process

without a matching CES answering to the requirements.

ii. Leveraging the reutilization of informatics (IT) systems or CES atomic

elements through the offered adaptive cooperation mechanisms;

o A system element (CES) can embed the computational (or

cyber-physical) mechanisms required for cooperation in

different scenarios, namely, different technology bindings for

equivalent capabilities. The cooperation is done through

associated metadata able to be interpreted by potential peer

clients both at the development and running time stages.

iii. Proposing a framework as a contribution to making the management of

complex collaborative solutions agile and autonomous, thus providing

dynamic adaptability to the network and systems management of

application/services.

o Given the growing diversity of systems, there is a need for a

unified systems' management for both monitoring and

maintenance under a unique Service Level Agreement (SLA)


84

framework. While this is not the focus of this research, the

adopted architecture establishes the basis for an adaptive and

intelligent integrated monitoring and maintenance processes

automation.

Based on the complexity of a preliminary prototype of a CES implementation

and the initial model described in [145], we propose a simplification [120], aiming

to facilitate its adoption.

Definition 1: CES. A Cooperation Enabled System (CES) is an autonomous

computational entity with an independent deployment and operation lifecycle, and

defined as a tuple: CES = (I0, SA, CS), where:

• I0 is the system Interface, a standard entry point used by peers to access

metadata and CES services;

• SA is the embedded self-awareness meta-data making CES aware of

peers implemented capabilities; the access to SA capabilities is through

I0;

• CS is the set of implemented services, accessible through the interfaces

CS = {I0, I1, …, IN}, where N ≥ 1, each interface being an interaction

point or cooperation point.

The proposed model maintains the essence of the concept introduced in [145],

considering that security, monitoring, events, and resources management are part of

the CS interfaces. The CES interfaces represent services potentially implemented

based on different technology frameworks. The SysML modeling language is

adopted to detail the proposed framework. Figure 22 depicts the CES and service

concepts represented by the SysML block modeling entity. The CES concept

implements the Service0 (I0) interface and is a composite of zero or more services

(I1, …, IN). The SysML InterfaceBlock models Service0’s single SelfAwareness()

method, returning a CES with the definitions of the implemented services.


85

Figure 22 – The Collaboration Enabled System/Services (CES) SysML model

One main concern during the CES design was simplicity as a strategy to address

the complex systems integration problem domain. The CES abstraction has an

associated version, the identification of its owner (supplier/producer) and it might

have an associated conforming certificate declaring it follows a reference model

(Reference CES attribute). The Service0 and the other offered services abstract

implementations developed under a specific technology framework with

specification obtained from the couplingData service attribute. The proposed model

makes CES implementing services based on different technology frameworks.

An important aspect of the proposed concepts is the generalization of the

implemented interfaces (the services) making it possible for a CES to adapt to a

diversity of execution environments. For instance, the roadside equipment (RSE) has

the autonomy to store vehicle identification events; when reestablishing the

connection with the lane management service (LMS), there is a potential need for

exchange of a considerable amount of stored data. While a file transfer mechanism

can be selected, other implementations can be available through web services or

another inter-systems communication mechanism (FTP, RMI, .NET, MOM, etc.).

The CES adaptability facilitates coping with scenarios involving multiple

technologies. Our approach can be a facilitator for standardization efforts at higher

modularity abstraction levels, centered on problem domain semantics rather low-

level technology specifications.

According to the above definitions, the CES services are characterized by the

Generic Modeling Entity (GME) concept as depicted in Figure 23. A GME object

hides the technology specificities. A GME instance represents any data expressed by

the byte sequence metaData contentType attribute. This way, any CES element can


86

be introspected through the SelfAwareness() method to obtain the implementation

details. The implementation details are decoded through the MIME-Type tag, the

contentType attribute. The SelfAwareness() method and the MIME-Type identifier

is the single conventions that are used to couple peer clients to the implemented

services.

Figure 23 - The SysML model of the Generic Modeling Entity (GME) value type

A GME instance is therefore composed of one MetaData and one DataObject,

objects. The MetaData value attribute contentType identifies a default known

structure of the content identified by a MIME-Type tag. To establish an interaction,

a peer service (CES element) needs a priori understanding of the contentType value

attribute of the target service (also a CES element). A contentType tag establishes

the correspondence to a specific technology framework where the DataObject

content embeds the necessary coupling data (e.g., configuration, security). For a

contentType value with service/ces.jini MIME-Type value, it means that a peer client

has to lookup services from a Reggie service (JINI lookup service).

The next subchapter discusses the framing of CES elements into the system and

system of systems context.


87

4.2.2 Isystem of systems (ISoS)

One main research objective is the organization’s open integrated informatics

systems landscape. The endeavor relies on the Informatics System (Isystem) and

Informatics System of Informatics Systems (ISoS) abstraction. Before the section

4.2.2.2, centered on ISoS, first the next section, 4.2.2.1 discusses the Isystem

abstraction and its relation to CES and to the Service concept.

4.2.2.1 The Informatics System (Isystem) Abstraction

An Isystem is a logical composite of one or more CES elements. Our open

informatics framework structures any computational responsibility under the CES

abstraction. For the sake of simplicity, it is possible that an Isystem is structured as

a single CES element, the CES0. The design of such an Isystem can be used to

integrate legacy systems where the single CES0 can be used to incorporate the

necessary integration computing logic. The Isystem’s internal structure is, however

dependent on architectural decisions, and they can range from a minimum of CES0

to including any number of CES elements. There is yet a limit (optional) situation

where a CES exists as an independent computational entity. Such an autonomous

system is possible since a CES implements the SelfAwareness() method representing

the service0. The interactions from a peer computing entity can be established

through the corresponding SelfAwareness() entry point. However, to be part of an

ISoS technology landscape, a CES needs to embed the Isystem abstraction. The

Isystem concept differs slightly from system definition since an Isystem’s element

cannot be an Isystem itself. The Isystem is a CES composite, each one structured as

a composite of services. Isystem abstraction offers a flexible and straightforward

(system level) modularity for organizing multi-supplier atomic CES elements under

a unified management framework.

Given the complexity of the organization’s informatics landscape, the Isystem

abstraction is introduced to establish a higher-level computational responsibility, as

depicted in Figure 24.


88

Figure 24 – The SysML model of an Informatics system (Isystem)

The Isystem concept answers the substitutability research question at two main

levels: i) the CES as part of an Isystem and ii) the Isystem as a composite of CES.

Definition 2: Isystem. An Isystem is a three-tuple: Isystem = (I0, SA, MC),

where:

• I0 is the entry point service for the self-awareness mechanism

responsible for adaptability;

• SA is the Self-Awareness element, following the CES definition;

• MC is a modular composite based on CES (CESc) or other equivalent

structure. If a CES composite, CESc = {CES0, CES1, …, CESN} where

N ≥ 0; and the CES0 is the system CES or meta-CES, responsible for

managing the composite. The respective I0 (service0) is the entry-point,

made effective by the SelfAwareness() method. To deal with legacy

assets, the model does not impose a strict CES implementation.

However, the SA (I0) entry point needs to be consistent with the

service0 (I0) of the CES model specification.

The CES abstraction substitutability is an important aspect of elements of an

Isystem. The substitutability requires however more than a common integration

framework. There is a need to agree on boundaries for the computational

responsibility to be worked on the reference models of both CES and Isystems. The

substitutability shall primarily consider the CES abstraction, founded on its

simplicity as Isystem element. Therefore, a CESx has a substitutable CESy if the

services implemented by CESx are structurally and semantically equivalent to the


89

services implemented by CESy. Both CESx and CESy need to implement migration

mechanisms (services) able to recover current and historical state data. The

migration capability requires that a CES implements specialized migration services

invoked during the substitution process. The substitution process might be complex,

and it might require human intervention. Nevertheless, the model assumes the

development of standard mechanisms for each class of CES, making competing

products substitutable.

The substitutability is a challenging endeavor managed depending on the

complexity of the Isystem. In more complex application domains, it is difficult to

establish a reference model for an Isystem. An enterprise resource planning (ERP)

Isystem is an example of such difficulty since a reference model, and a conforming

certification process conflicts with the diversity of the organization’s specific

processes (specific requirement capability mappings). For such cases, the ISoS

model suggests a conformity certification process at the CES level, thus guaranteeing

that, at least, parts (elements) of an Isystem have more than one supplier. For the

cases where the semantics of the computational responsibility border is consensual,

i.e., it is possible to agree on a complete enough reference model and

implementation, the substitutability can take place at the Isystem level.

The proposed Isystem model renders a transparent computational

responsibility, hiding internal technology, data schemas, or process modeling

options. Such a response can be organized as CES adaptive components potentially

running on different virtual execution environments, managed by a CES0. The

Isystem model facilitates having CES elements running on different (distributed)

execution environments (e.g., cloud or on-premises), as discussed later in this

subsection. Furthermore, other features commonly associated with informatics

systems developed under current practices need to achieve a minimal completeness

degree (increasing the potential to be adopted by real cases). Examples of such

concerns are:

i. Federated data sharing, data exchanged between CES, and data

management (data lifecycle management; backups/recovery, historical

data management);

ii. Unified authentication and Role-Based Access Control (RBAC);

iii. Isystem administration considering a unified approach to the

administration of each CES;

iv. Unification of the user interface considering the participation of each

CES for some aspect of user interaction;

v. Unified security strategy for data privacy, data integrity, and

(programmatic) access to computational services.


90

To cope with the underlying complexity, the adopted strategy was designed to

be as less intrusive as possible for legacy systems. Therefore, to address an

organization’s level coordination, we propose establishing the organization’s

informatics system of systems (ISoS) as a top-level abstraction discussed in the next

subchapter.

4.2.2.2 The Informatics System of Informatics Systems (ISoS)

The ISoS is based on an Isystem0 (Isystem zero or meta-Isystem) playing a

coordination role for the informatics systems landscape. Therefore, Isystem

abstraction can wrap legacy systems by restricting changes to the instantiation of the

proposed concepts, thus maintaining the integrity of implemented specificities, i.e.

the legacy technologies and development processes.

Therefore, the ISoS framework is defined as follows:

Definition 3: ISoS. An Isystem of systems (ISoS) is a three-tuple: ISoS = (I0,

SA, ISC), where:

• The I0 is the entry point service, supporting the self-awareness

mechanism, following the I0 service of a CES and Isystem;

• The Self-Awareness (SA) follows the Isystem and CES definitions;

• The Isystem composite (ISC) is a set ISC = {Isystem0, Isystem1, …,

IsystemM}, where M ≥ 0; the composite of Isystems is also represented

through Isystem0.

Following the adopted strategy, for an organization to be considered compliant

with the ISoS framework, an equivalent Isystem0 and the corresponding I0 (accessed

through the SelfAwareness() method) is necessary. Figure 25 depicts the ISoS

modeled by the SysML block modeling element. The Isystem0 is a specialization of

the Isystem and establishes the ISoS technology landscape. Through Isystem0, it is

possible for any deployed Isystem to lookup any other Isystem, and to “learn” about

their capabilities, and how to interact with the available services (potentially

developed on different technology frameworks).


91

Figure 25 – The SysML model of the ISoS Framework

With the ISoS abstraction being established, in the next section, we discuss the role

of Isystem in the proposed adaptive integration of the organization’s informatics

technology landscape.

4.2.2.3 Role of Isystem

The Isystem0 plays the roles of enterprise integration, coordination,

operationalization, and mediation. Through the Isystem0, the proposed ISoS

framework establishes an Open Adaptive Coupling Infrastructure (OACI) [120], as

a generic logical bus connecting the enterprise Isystems, as illustrated in Figure 26.

Comparing to the enterprise service bus (ESB) where one or more informatics

systems mediate the required interconnections, the OACI is based on the simple

Isystem0, CES0, and I0 mechanisms to establish peer-to-peer adaptive

interconnections among Isystems (adaptive integration strategy). The integration

mediators (integration hubs) playing a specialized integration role can exist under

the proposed ISoS framework as a dedicated (potentially substitutable) Isystem. The

Isystem concept models every shared informatics capability.

Figure 26 depicts ECoM (addressed earlier in section 5.3.1) computations

responsibility [159], providing collaborative capabilities as an example of a

specialized Isystems in an ISoS organization’s technology landscape context. The

other Isystems can lookup and obtain credentials to access the ECoM services, from

the organization’s Isystem0 through the service I0 of its CES0. The ISoS framework

enables the organization’s informatics landscape to evolve to a coordinated

composite of Isystems, potentially substitutable if developed under open

specifications and when the competing Isystems are in place.


92

Figure 26 – The organization’s Isystem of systems (ISoS)

The Isystem0 is a type of meta-Isystem responsible for coordinating the

remaining deployed Isystems. It can be of the responsibility of an Isystems to

implement common governance functions, e.g., unified security, services discovery

mechanisms, and user authentication and authorization services. The Isystem model

is flexible enough to support CES elements distributed across on-premises or cloud

computational resources. Such flexibility is possible because the CES0 component is

responsible for the management of the Isystem composite as a coordinated composite

of CES computations responsibilities.

The ISoS framework makes it possible to evolve legacy ITsystems towards

managed Isystems. Its simplicity stems from the freedom of a legacy system

developer (supplier) to continue adopting its technological frameworks. The ISoS

unified entry point to access an Isystems goes independently through the Isystem0 if

Isystems are wrappers for legacy enterprise applications or new systems.

Furthermore, common computational responsibilities can be shared under the

Isystem model, making them available for other Isystems or (wrapped) legacy

systems. As an example, the authentication and authorization capabilities can be

centered around a specialized Isystem, accessible by other Isystems when user

authentication or access control is to be granted, and depending on the security needs.

The deployment of an Isystem is another important issue that is discussed in the

next subsection 4.2.2.4.


93

4.2.2.4 Deployment of Isystem

The CES elements of an Isystem can run on-premises or in the cloud. As an example,

the open-source Spring Cloud framework [31] is a candidate technology to run the

services of a CES element. The cloud awareness makes ISoS close to the

microservices trends where fine-grained computational responsibilities executed on

autonomous (isolated) containers [12]. In our approach, no restrictions exist for the

adopted technology frameworks. Furthermore, The CES elements are like

microservices that can be instantiated on-premises or in the cloud computing

infrastructure, as depicted in Figure 27. In the fast-growing microservices research,

there is a recurrent discussion quasi-exclusively centered on the cloud, e.g. [64], [12],

[40], to mention only a few research works.

Figure 27 – Management of heterogeneous execution environments

4.2.2.5 Purpose of Isystem

The proposed ISoS framework establishes a rupture concerning other more

conservative approaches arguing in favor of the servitization process enabled by

information technology [82]. The microservices movement has the advantage of

breaking monolithic designs into fine-grained and applying language-agnostic

remote application programming interfaces RESTful or RPC paradigms. However,

such finer-grained computing responsibilities, while presenting some advantages

[64], are centered on cloud-addressing scalability and reliability, since dependencies

rely on an increasing number of distributed elements. The scaling of elements arises

in part from the adoption of fine-grained computational responsibilities.

Management of such fine-grained elements requires more than a neutral application

programming interface (API) [5], it requires a language/technology independence

(isolation). Therefore, such increasing complexity means that beyond the effective


94

mechanisms to make a service orientation (fine-grained Isystems and their CES

elements), there is a need for a strategy to cope with the increased complexity of the

new distributed and heterogeneous integrated computational systems, which we

identify as informatics systems of systems (ISoS).

4.2.2.6 Reference Model for Isystem

To succeed in making our approach effective, the development of reference

implementations for canonical (reference) models, for such fine-grained

computational responsibilities, is of paramount importance and causes the promotion

of technology independent CES elements. The leading market nowadays pushes

under a fierce dynamism to offer (unique) innovative computational solutions.

However, the change for a technology-agnostic framework needs to be moderated

by large users-organizations, namely, public administrations on promoting unified

approaches, under a strategy to promote competitive market tenders. The recognition

that development of competitive tenders is a complex endeavor is also a motivation

for the collaborative enterprise development environment (CEDE) initiative, as

discussed further in Chapter 5.

To differentiate our research on reaching open modularity for the complex

informatics system of systems, we further define and formalize the substitutability

and the equivalence between Isystems and Isystem’s openness as follows:

Definition 4: Openness. An Isystem is open x (CESx) if y: CESy

CESx. Two CES components are equivalents if CSx CSy and the services are

structural and semantically equivalent. An open Isystem is also said to have all

its CES under external modularity [149]. If not all CES are substitutable, the

Isystem is said to be partially open. In a closed Isystem none of its CES are

substitutable. In this case, we say that the Isystem is developed under an internal

modularity strategy. A CES element is said to be open if under external

modularity.

Definition 5: Substitutability. An Isystem is substitutable x (Isystemx

S) if y: Isystemy Isystemx is the capability of a CES or an Isystem that can

replace them by an equivalent through a migration process. Substitutability can

happen at two different levels: (i) Isystem level (substitutable CES), and (ii)

ISoS level (substitutable Isystems).

Definition 5.1: Equivalence. Two Isystems are equivalent, or Isystemx

Isystemy, if MCx MCy and the services are structural and semantically

equivalent (where MC is a modular composite as formulated by definition 2).


95

Definition 5.2: Partial Openness. An ISoS is open (ISoS O), if x, y:

Isystemy Isystemx. If x: Isystemx S then the ISoS is said to be partially

open (ISoS Op). If x: Isystemx S then the ISoS is said to be closed (ISoS

C).

As we will discuss in Chapter 7, our research on ISoS framework will further

continue and extend under an open, collaborative dynamics led by the science and

technology community in collaboration with the industry. However, based on our

empirical experience through its adoption for Brisa’s innovation process, we

conclude that the proposed and so far developed framework constitute contribution

beyond the state of the art in realizing the modular enterprise architecture [165],

while able to incorporate existing standardization efforts like the Partner Interface

Process (PIP), and following developments already underway by RosettaNet20 and

other standards organizations.

Section 4.5 presents and discusses a simple example of our proposed framework

in an application in the tolling domain.

4.3 Substitutability of CES and Isystem

The ISoS approach aims to establish an open enterprise framework for organization’s

informatics systems based on mechanisms to evolve for a multi-supplier technology

landscape. However, such an evolving process requires complementary semantics

standardization effort. Our definition of substitutability (definition 5) challenges the

possibility for an Isystem to be substituted by a competing implementation from an

alternative supplier (eventually motivated by costs or quality advantages). The

substitution can occur at: i) CES level, or ii) Isystem level. The substitution

capability is also related to how services are defined and implemented (I0, …, In) for

both CES and Isystems. In the case of Isystems, we refer to services implemented by

the corresponding CES0. When we consider Isystem services (I0, …, In), we are

pointing to the services implemented by CES0 element.

Despite the similarity of substitution of CES and Isystems, the substitution at

the Isystem level tends to be more complex considering it may be a composite of

CESs. The complexity also depends on architectural decisions guided by simplicity,

reutilization, and a clear separation of responsibilities. To apply the substitutability

20 RosettaNet is now being maintained by GS1 (https://resources.gs1us.org/RosettaNet)


96

principle, beyond compliance with the ISoS framework definitions, a semantic

standardization is of paramount importance. The following subsections further

discuss the proposed modularity levels, and addresses the atomic – CES, and the

molecular - Isystem, in a discussion centered around the required semantics

agreements, as a necessary dimension to guarantee their substitutability.

4.3.1 Substitutability principle at CES level

The atomic modularity at the CES level aims to promote an industry supply based

on components able to contribute to an enhanced and competitive informatics

systems market. The roadside equipment for tolling is an example, demonstrates the

CES applicability. Beyond the structural standardization, there is a need to promote

a semantics convergence establishing unambiguous capabilities through a

conformity certification process. The multivendor objective requires development of

a reference model for each standardized computational or cyber-physical

responsibility, agreed and validated through a reference implementation, which in

turn can be used to assess the compliance of candidate products, through a tendering

process for instance.

The CES modules are a necessary condition to evolve to multivendor

informatics and cyber-physical technology landscapes. CES modules present low

intrusiveness as each product developer has the freedom to adopt the technologies to

implement the required functionalities. Any supplied product must be only in

agreement, in terms of interfaces e.g. for its capabilities to be represented as services.

The proposed ISoS framework suggests that domain-specific taxonomies of

Isystems and CES components elements be defined and guided by the

substitutability principle. For the next example, we will consider the Electronic Toll

Collection (ETC) application, discussed in the context of the ITSIBus formulation

as addressed earlier in subchapter 3.3, redesigned to frame ISoS. For an open ETC

we have developed reference architectures and reference implementations for the

parts that may have more than one provider. Based on the ETC general architecture,

discussed in Chapter 3, adapted to fit the ISoS framework as depicted in Figure 28,

seven potential CES components are defined: central Toll Management System, Toll

Plaza system, Lane System (Via-Verde), vehicle identification RSE/DSRC, vehicle

classification AVC, paid toll Display, and license plate enforcement LPR.


97

Figure 28 – The open Electronic Toll Collection Isystem as CESs

The main difference between the ITSIBus and the ISoS concerns the approach

adopted for modularity, through the CES concept. In the ISoS framework, peer

elements need only to know the I0 entry-point for obtaining through introspection

details about the implemented services (capabilities). One way to do this can be

through rethinking the application layer as defined in the current versions of the CEN

TC-278 standards, making a Road Side Equipment (RSE) a plug-and-play and

substitutable CES component. Beyond the computational aspects, the substitutability

also depends on electrical and mechanical interfaces, aspects that under the proposed

systemic approach to the ETC, should also be included as standardization goals.

The next subsection discusses both the Isystem modularity granularity and the

hypothesis of alternative modularity strategies for the ETC informatics system.

4.3.2 Substitutability principle at Isystem level

The ISoS framework assumes that modularity can occur at both CES and Isystem

levels. The modularity strategy to adopt depends on the ability to define a modular

granularity that can motivate the market to develop conforming products. When

comparing the cyber-physical RSE system and the toll plaza controller, the RSE is

expected to scale and to be simple to normalize considering its limited capabilities.

However, for the toll plaza, the standardization is more complex since the

computational responsibility must implement a larger set of capabilities. The

difficulty in establishing external modularity requires a flexible approach to model

computational responsibilities, taking advantage of the simplicity of the proposed

ISoS framework.

We can also approach the ETC example from a different angle, i.e. using a

different strategy. Instead of designing the ETC as an Isystem made of a set of CES


98

components as depicted in Figure 28, we can consider the ETC computational

responsibility as a set of Isystems, as depicted in Figure 29. The two approaches,

although look similar in their figures, follow different design strategies requiring

different standardization efforts. Furthermore, in the first case, the RSE is a CES,

and in the second case, the RSE is an Isystem. Therefore, an important aspect to

emphasize here is the independence of the ISoS framework from the best modularity

strategy that can be adopted.

Figure 29 - The open ETC as a set of Isystem

From the theoretical foundation's point of view of ISoS, the modeling strategy

conflicts with the commonly assumed relationship between a business contracted

responsibility and the structuration of the organization’s informatics system. In other

words, the structuration proposed in Figure 29 is possible but leads to complex

roadside cyber-physical systems interactions. The RSE is modeled as an Isystems

with the respective CES0 element. The main issue is in the lack of a mechanism to

group a set of Isystems and to make them a single logical unit under a unified ETC

informatics responsibility. On the other hand, by adopting the approach depicted in

Figure 28, the ETC is modeled as a coherent single logical entity made of CES, for

which at least some components (Isystems) might have more than one supplier.

It is empirically demonstrated that the substitutability is much more complex at

the Isystem level. The SINCRO case is an example where the multi-supplier

paradigm for the Portuguese national vehicle speed enforcement network was

adopted. A unified concept of roadside enforcement point and its two main

components the cinemometer (radar) system and the cabinet were designed and

prototyped in cooperation with the potential suppliers and later adopted by most of


99

them. However, a similar unified concept was not possible to achieve for the central

back-office system where policies validate traffic events, as also discussed in more

detail in Chapter 6. It is important to mention that the convergence for unified

interfaces at roadside enforcement locations was actually achieved during the

preparation of the technical tender specification, due to the interest of potential

bidders. The standardization process became simplified because the market already

had developed a similar approach for a road enforcement point. However, the same

did not happen for the central back-office system. The issue was in obtaining a closed

set of requirements able to validate an independent technology implementation for

the market to adapt their offers. The ISoS framework is motivated by the lack of a

strategy for an open back-office system.

Despite the difficulties of achieving interoperability at the Isystem level, the

ISoS framework adopts a strategy to make it feasible. There is a need for reference

architectures, and reference implementations potentially developed under an open or

community source policy, to establish a semantic normalization effort targeted

towards Isystem substitutability. However, we believe that such a process will be a

long-term goal. Partial substitutability can be obtained in the short term, starting

from specialized responsibilities, as it was the case with Brisa/ETC,

ANSR/SINCRO, and BP/HORUS cases, which are discussed in Chapter 6.

4.4 Process Modeling Paradigms and Standards

Maintaining updated models of Isystem technology landscapes is a complicated

endeavor. The lifecycle management of heterogeneous systems requires multiple

background competencies, given the diversity of adopted technologies and the lack

of an open modularity framework. It relies on complex relationships with

participating vendors. When changes are needed, underlying models are challenging

to maintain and evolve. Domain experts commonly addressed the formulation of

automation problems in collaboration with informatics engineers (accounts, traffic

managers, safety planners, logistics planners, and operators). The conventional

approaches follow the analysis of requirements as formulations about what is

expected and as a result producing a delivery with the technical specifications for a

tender. As discussed in [149], neither models nor standards are complete enough to

support such a closed-loop, guaranteeing at any time the substitutability of the

adopted Isystem. With the ISoS separation of concerns based on the proposed

Isystem/CES modularity abstractions, several tools such as Isystems can contribute

to the integrated management of the ISoS Isystems lifecycle management.


100

In the following two subsections, we discuss modeling issues by emphasizing

the complexity to model/implement an integrated ISoS. Our thesis is founded on the

idea of establishing a clear responsibility boundary and the separation between

software engineering strategies and informatics systems engineering, by adopting

systems thinking [94], to develop a complex ISoS technology landscapes.

4.4.1 Systems modeling paradigms

Despite the many standardization efforts based on a diversity of Domain Specific

Language (DSL), a unified approach is lacking. The development of languages like

the OMG’s standard Semantics of Business Vocabulary and Business Rules (SBVR)

[137], the diversity of specific solutions prevails. The Decision Model and Notation

(DMN) standard [136] of the responsibility of OMG seems to lack any relation to

SBVR. Another interrelated model specification, the Business Motivation Model

(BMM) [134], which aims to establish standard concepts for defining business plans,

seems to lack any relation to DMN and the Business Process Model and Notation

(BPMN) [135]. DMN and BPMN are essential as a strategy to reduce to a minimum

time between the formulation of some new business strategy and its implementation.

In the statement “Advanced Concepts for Architecture Support Process-driven

applications Architecture in Process-Driven Applications” [182], the author does not

associate the main problem with the software development. The argumentation is

founded on the enormous advancements in software engineering - i) model-driven

software development; ii) the standardization of communication and interface

technologies; iii) the modularization of business functions in the form of reusable

services; iv) productivity improvements for software developers due to highly

integrated development environments; and v) the development of agile development

methods. Instead, in [182], the author associates the problem with maintaining and

adapting to changing conditions.

More recently, the system modeling language (SysML) [139] has been

positioning as a modeling paradigm addressing requirements to both structural and

behavioral modeling aspects. Although other similar modeling languages like the

contemporary Object-Process Methodology (OPM) [44] have been proposed, the

SysML is emerging as a de facto standard to support Model-based Systems

Engineering (MBSE) [86]. Beyond SysML language as a key enabler towards more

consistent lifecycle management of organizations technology landscape, other

modeling mechanisms would be necessary, namely a specific ISoS modeling profile.

As a rather novel science and engineering area, informatics science and

engineering has been smoothly converging towards a distinct identity making the

existence of semantic misunderstandings as natural. Nevertheless, the convergence

4.4 Process Modeling Paradigms and Standards

101

towards common consensus models is difficult since it challenges cultural and

business interests. The Cooperation Enabled System (CES) component framework

promotes the idea of convergence, while not imposing specific paradigms and

technologies.

The next subsection discusses how ISoS framework relates to model-driven

approaches in informatics systems development.

4.4.2 Agile bind of process activities to Isystem and CES components

The proposed ITSIBus modeling framework, as discussed in Chapter 3, suggests the

adoption of declarative approaches for the lane controller adopting a process

definition and execution strategy. The proposed modularity facilitates the proposed

process-oriented development since CES or Isystem composites encapsulate specific

technology cultures. The fact that the BPMN language already considers BPEL as a

binding language for the generation of executable process definitions turns the ISoS

into a strategy to potentially speed-up the adoption of process-driven developments

[158], [182].

A process-driven application (Isystem) is defined “as a business-oriented

application that supports differentiating end-to-end business processes spanning

functional, system, and organizational boundaries by re-using data and functionality

from platforms and applications” [182]. However, we argue that the lack of a clear

separation of (computational) responsibilities has, on the one hand contributed to

complex integrated artifacts and on the other hand, it has been an obstacle to a

generalized adoption of such a valuable declarative approach to Isystems

development. In spite of the paramount efforts to grasp a process-driven approach to

Isystems development, the reality has demonstrated that it is difficult to

operationalize the existing technology landscape of organizations, mainly due to the

multiple dimensions of the well-researched “misalignment between business and IT”

[7]. However, even if we empirically believe that the proposed ISoS framework is

expected to facilitate the adoption of a process-driver paradigm, achieving a de facto

adoption of this approach needs some further research, as discussed in Chapter 7.

In our research, the main concern was to establish an adaptive modularity

framework able to plug a higher-level strategy towards declarative development of

required behaviors. One important aspect is to explore the SysML activity diagrams

and their relation to BPMN since they share common modeling elements with similar

semantics, and they are both processes modeling languages [48].

The next section 4.5 discusses the ETC case intending to demonstrate the

flexibility of the proposed ISoS framework to support a convergence for an


102

integrated modeling approach for the integrated organization’s technology

landscape.

4.5 Open ETC Case

To better understand the ISoS framework and the proposed CES and Isystem

concepts, we propose and discuss a redesign of the mentioned Electronic Toll

Collection (ETC). As presented in Chapter 3, roadside equipment (RSE) reads the

electronic vehicle identification data from an onboard unit (OBU). The ETC Isystem

manages a network of tools plaza management services, and for each plaza, there are

several lane management services. The lane management services coordinate events

from roadside equipment (RSE), a vehicle classification element (AVC), and an

automatic vehicle identification through its license plate recognition. At the lane

level, a typical electronic toll collection system has a lane controller that coordinates

events generated by vehicle detection and classification and an enforcement ALPR

subsystem. A central coordination service (CCS) manages toll transactions managed

by a toll plaza management element which is responsible for coordinating lanes as

depicted in Figure 30.

Figure 30 – An Electronic Toll Collection as an Isystem

Our proposed ISoS framework considers specialized system CES, offering

communication and coordination mechanisms for the entire solution of the ETC use

case. The CES is grounded on the experience and results from the adoption of the

ITSIBus by Brisa as a service-oriented (SOA) tolling infrastructure [147]. The

implementation of some of the features proposed by ITSIBus evolved to CES, like

the service monitoring, which has contributed to reducing the total cost of ownership

(TCO) of the deployed technology systems. CES has also contributed to simplifying

4.5 Open ETC Case

103

and increasing competitivity in the evolution of new services, as in the case of the

more recent deployment of a new self-service tolling lane type (eTOLL).

Furthermore, the ISoS open framework establishes a less intrusive approach,

since for an element to be an Isystem, it only needs to make available a set of services

according to the Isystem definition. Our approach means that the Isystem intrinsic

implementation details are not relevant for its integration into an ISoS landscape.

The necessary condition for the integration is that both implementations conform to

a common Isystem’s reference model. One main objective for adopting such a

strategy is to establish a dynamic adaptive modular framework to minimize the need

for unification of models or technology. A paradigmatic counterexample is the

CORBA standardization effort, where a total unification strategy was adopted, even

when considering different support for different language bindings. The complexity

of the developed specifications did not allow for convergence of implementations.

In the next sections, we further discuss the Openness of the proposed ISoS

framework and the related substitutability principle as an important dimension for

the proposed framework.

4.6 Strategy for an Open ISoS Framework

The ISoS framework is a set of Isystems composed of CES, under a simple adapting

mechanism. Only the SelfAwareness() service is standardized by fixing the

technology bindings. A peer computational entity must access the SelfAwareness()

web service to interact with an ISoS element of the CES it wishes to access. The

design for the ISoS framework considered the cost for a supplier to adapt their

informatics or cyber-physical systems, simplifying it. It also answers the requirement

formulating the need to preserve both legacy and new technology diverse, and

making decisions independent from technology evolution and innovation.

In this subsection, we discuss the strategy to follow in order to develop the

organization’s informatics systems landscapes evolving towards an open technology

infrastructure. Based on the experience of developing research projects in

collaboration with the industry, openness is not exclusively dependent on technology

decisions. The trend for complex technology landscapes has increased the pressure

over IT managers since they must assume the responsibility of operational risks. In

many cases, the risks are mitigated by maintaining vendors and giving them the

responsibility to answer to new requirements. The created dependencies result in the

costs of software licenses or services that cannot be moderated by competing


104

suppliers. In many cases, the implementations follow technology design decisions

depending on processes and technology cultures of a specific vendor [149].

In section 4.6.1, we discuss the substitutability principle as a guideline to evolve

from monolithic and technology-dependent landscapes to open infrastructures and

systems. We also clarify how ISoS can help solutions to evolve towards a declarative

process-oriented development based on the proposed open adaptive modularity. In

section 4.6.2, we detail aspects related to the validation of systems and elements, as

a strategy to enforce the maintenance of a path to open enterprise informatics

systems.

4.6.1 Substitutability principles

To keep the ISoS framework simple, substitutability depends on specialized

functionalities (capabilities) implemented by CES elements or Isystems. Our

approach does not require additional structures since specific services are enough for

both import state data (state and historical) from the substituted Isystem (or CES)

and export such data sets when to realize a substitution. The proposed strategy

requires the verification of two main conditions:

i. The two Isystems or CESs that are considered to be replaced with each

other must comply with the same reference implementation. They

should provide equivalent capabilities and implementing import and

export services for both state and configuration data. Depending on the

range of computational responsibilities, migration of services is

expected to be a complex endeavor. We discuss in more detail these

aspects in Section 4.6.2;

ii. There is a need to maintain the Isystem or CES without any change that

can condition its conformity. The immutability of a product is perhaps

the most challenging issue, since requirements evolve under a rhythm

that is not compatible with restrictive changing rules. Our research

demonstrated that the substitutability of a roadside CES element is

possible, e.g., in the road speed limit enforcement, when the SINCRO

network removes a cinemometer, namely when the state data is

preserved. However, depending on the complexity of the state data, the

exchange process is expected to be a complex one.

Our main concern was to establish the mechanisms enabling the substitutability.

The operationalization of substitution requires an imperative determination from the

user-organizations to evolve towards technology-agnostic solutions. To this end, the


105

ISoS framework considers a complying certification process based on reference

models and validation through reference implementations in helping to validate if

products are according to the established models for each Isystem or CES. Figure 31

depicts the SysML model of the concepts supporting the conformity certification

process. Any Isystem or CES shall have an associated reference model (“Reference

Isystem” or “Reference CES”) as specializations for both “Reference Model” and,

respectively, Isystem and CES. An example of a “Reference CES” is the roadside

equipment “Ref RSE” which can have implementations from Q-free and Kapsch,

among other potential suppliers.

Figure 31 – The SysML model of Isystems and CES standardization elements

The development of open Isystems faces many challenges both technical and at

a business-processes level. For the ISoS to succeed at the Isystems level, there is a

need for change in the current informatics developments practices. As discussed, the

trend for a direct mapping between requirements and software development

specifications needs to evolve towards a system’s thinking by mapping process

automation requirements to systems or system elements. The process is expected to

be challenging, when considering the complexity in standardizing all the cases.

Complex solutions tend to be implemented by large market informatics industry

companies commonly responsible for complex technology infrastructures and

systems. We argue that such a move for open informatics systems requires

investments in the convergence towards finer-grained modularity. The ISoS

framework demonstrates the realization at the CES level. The complementary

strategy is to evolve under an open specifications program, as suggested by the


106

Model Driven Open Systems (MDEOS) [149] and discussed in Chapter 6, Research

and Development Results Validation.

4.6.2 Conformity certification process

A key strategy to evolve towards an ISoS framework is the convergence towards

informatics system elements that can be replaced by competing products. Existing

standards are not complete enough to address the complexity of the total integration

trend under multi-supplier technology setups. Furthermore, the attempt to unify

different levels from the conception to implementation has failed to be complete

enough to grasp, under a unified approach, all the variables in real-world use cases.

Also, different semantic interpretations of the existing specifications led to

incompatible implementations and, therefore, to technology dependencies. Thus, it

is of paramount importance that the convergence for reference models of both CES

and Isystem elements be founded in reference to implementations. These can be used

by independent certification organizations to moderate market competition.

Independent certification of products is motivated by the need to validate quality,

security, performance, and other features commonly dependent on specific

implementations without any formal validation process. Conformity certification is

of prime importance for the public sector to manage open tenders, where the

validated quality and cost shall determine the bidding winner. The SINCRO research

case is an example of such an effort to evolve towards an open validated system’s

features. A speed enforcement system21 is expected to be certified against SINCRO

specifications and metrics to measure the quality of collected traffic events (speed

enforcement). Since more recent cinemometers collect evidence from different

lanes, the open question is to establish a quality rate, i.e., a ratio between the number

of vehicles crossing the enforcement location under excess speed and the number of

collected events. The certification of operational quality and other features can help

to establish standardization efforts involving potential suppliers and moderated by

public organizations.

Therefore, the ISoS framework assumes a suit of reference models validated by

reference implementations establishing standard Isystems or CES elements. The

CES elements embed the diversity of existing and novel technology approaches.

Moreover, the ISoS framework minimizes the required consensus on technology

options to a simple web service basic profile. The proposed simplicity implies that

the standardization shifts the perspective from technology to business and processes

21 A ciberphysical system commonly used by police to enforce vehicle speed, in

Portuguese, cinemómetro.


107

design decisions viewpoint. The ISoS framework can also be considered as a

contribution to a systems-based development rather than a software development-

centric approach.

4.7 Summary

The Informatics System of Systems (ISoS) framework is based on the two main

concepts, the Cooperation Enabled System (CES) and the Informatics System

(Isystem). The resulting framework adopts modularity based on computational

responsibilities, configuring as a set of capabilities organized as Isystems or CES

atomic system elements.

ISoS provides an open framework, to support adaptive cooperation among

different Isystems. It also offers a mechanism for composition of systems, as a

strategy to enable components' substitutability principle. Our planned substitutability

feature, while quite challenging to achieve, has constituted the main target and the

guiding principle for the design and development of the ISoS framework. This

approach establishes our so called "external modularity" in development of system

of systems, through which multiple suppliers can compete for development of the

required Isystem or CES components. Consequently, it also facilitates substitution

of an existing Isystem or CES, by one that is developed by a competing supplier.

Furthermore, it provides a strategy to heavily reduce the current vendor lock-in

situation, as typically faced in development of large system of systems. However,

the effective operationalization of the ISoS framework and its proposed strategy

needs to be preceded by the existence of a conformity certification program. Such a

conformity certification program validates if the open interfaces provided by

potential suppliers, accurately implement and can be verified against the required

reference implementation. It therefore supports offering of complying products and

potential contributions from diverse interested stakeholders that apply varied

technologies.

From our experience with the discussed developed research cases, in general,

convergence to a consensus is a risky and challenging process. In some cases, the

technology landscape is critical for the business; the associated risks commonly

follow a safe path by adopting a unique implementation responsibility, usually

represented by one integrator, assuming the overall coordination of both processes,

technology developments, and the integration of parts under specific constraints.

While the discussed trend for total integration, brings new risks, these are partially

mitigated by our proposed strategy for the open technology landscape through ISoS.

However, the mitigation of risks requires standardization initiatives for developing


108

reference models and reference implementations supporting the validation of

integrated solutions.

The ISoS can therefore be regarded as a path to an open informatics and cyber-

physical open systems technology landscape. In our opinion, the standardization

efforts centered on establishing the best granularity of “isolated/independent”

computational responsibilities (CES or Isystems) need to be led by user-

organizations. There is a need for the top decision-makers (from user-organizations)

to take the lead in this strategy and invest in the convergence for such an open

framework. The resistance to changes is commonly well-founded on risks and lack

of trust to involve new suppliers that potentially apply different processes and


109

Chapter 5

5 ECoNet CNO Infrastructure

and CEDE Development Platform

In this chapter, we address the need for adaptive informatics systems integration

motivated by the inter-organization collaboration or the so-called Collaborative

networked organizations (CNO) perspective [3]. There is a growing adoption of the

Electronic Data Interchanges paradigm based on an assortment of communication

protocols and data format and semantics. Such a variety of technology systems

establishes complex critical interdependencies and specific technological solutions,

not moderated by a competing market. The electronic toll collection and transports

and logistics cases, and the emergence of the Logistics Single Window (LSW)

concept [6] has motivated the research to develop a strategy for data interchange

management under a common framework for such growing interdependencies. Our

formalization of the Enterprise Collaborative Network (ECoNet) platform [159]

proposed in this chapter is an important research milestone and therefore its

validation scenario for the adaptive integration of informatics systems. Our research

suggests making each system independent instead of re-utilization of the business

logic shared by different collaboration contexts. This means that the "computational

market responsibilities", typically provided by different developers, will be as

autonomous and independent from each other as possible, even if this causes

replication through some of their shared function libraries.

This chapter also presents and discusses our Collaborative Enterprise

Development Environment (CEDE) [149] as a unified development environment to

converge towards open Isystems. The CEDE development environment is the

strategy to reduce dependency risks from unique Isystems or CES by adopting a

common suite of technology frameworks and tools. Furthermore, both the ISoS

framework and the ECoM Isystems, which together establishing our ISoS-CN, are

developed based on the CEDE platform.

Chapter 5 ECoNet CNO Infrastructure and CEDE Development Platform

110

The ISoS framework is discussed with the relevant strategies to structure the

participation of organization's Isystems in cooperative interchanges, under

collaborative business objectives. In section 5.1, we give an overview of

Collaborative Networks and Informatics Systems Landscape. We describe in Section

5.2 our proposal for modeling a Collaborative Networked Enterprise. In Section 5.3,

we apply the Isystems strategy to Collaborative Networks. Finally, in Section 5.4,

we describe the ISoS development strategy based on CEDE.

The following papers partially address the proposed formulations and discuss

problems and approaches towards a structured and adaptive extension of the intra-

organization informatics systems when participating in collaborative businesses:

• A. Luis Osorio, Lara Moura, Rui Costa, and Paulo Borges. Towards intelligent

mobility: The mobility intelligent, cooperative systems (MOBICS) platform. In

Proceedings of 7th Transport Research Arena TRA 2018, April 16-19, 2018,

Vienna, Austria, 2018.

• J.M.F. Calado, Luis A. Osorio, and Ricardo Prata. An adaptive IoT

management infrastructure for ecotransport networks. In Risks and

Resilience of Collaborative Networks, volume 463 of IFIP Advances in

Information and Communication Technology, pages 285–296. Springer

International Publishing, 2015.

• Luis A. Osorio, Luis M. Camarinha-Matos, and Hamideh Afsarmanesh. Econet

platform for collaborative logistics and transport. In Risks and Resilience of

Collaborative Networks, volume 463 of IFIP Advances in Information and

Communication Technology, pages 265–276. Springer International

Publishing, 2015.

• A. Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh. Enterprise

collaboration network for transport and logistics services. In Collaborative

Systems for Reindustrialization, IFIP Advances in Information and

Communication Technology. Springer Berlin, 2013.

• Luis A. Osorio and Luis M. Camarinha-Matos. Distributed process execution

in collaborative networks. Robot. Comput.-Integr. Manuf., 24:647–655,

October 2008.

• L. M. Camarinha-Matos, H. Afsarmanesh, C. Antunes, J. F. Clavier, C. Garita,

P. Gibon, A. Klen, H. Lenz, C. Lima, J. Mota, A. L. Osorio, R. Rabelo, H. Ribeiro,

A. Schreiber, L. M. Spinosa, and Y. Ugur. The PRODNET Demonstrator, pages

279–290. Springer US, Boston, MA, 1999.

5.1 Collaborative Networks and Informatics Systems Landscape

111


A growing number of organizations of all sizes are requested to adopt informatics

technologies as a necessary condition to remain in business. On the systems

interaction/integration side, this digital trend has led to the establishment of a

complex web of specific adapters, that are developed without a unifying strategy.

The LSW concept is an example of such a trend, as a central coordination entity for

the door-to-door freight guiding participating stakeholders. The stakeholders play

the role of transport companies, logistics operators, transportation authorities

(customs, phytosanitary, and ports) and other service providers. In the MIELE case,

section 1.1.4, we developed and demonstrated a strategy to establish a logical

unifying network to support the diversity of existing cooperative mechanisms -

namely specific adapters.

Beyond the electronic toll collection (ETC) application domain, where drivers

expect to travel different motorways or bridge concessions using a single service

contract, while also required in the logistics and transport domain, the networked

dimension requires adopting a concise approach. Considering that business

processes cross groups of organizations (as stakeholders), their infrastructures, e.g.,

gates at harbor ports or warehouses and depots, in the capacity elements of their

informatics systems, need to interact with embedded trucks or driver’s mobile

devices. Such complex growing interactions need to support consistent, scalable

distributed business processes with activities from heterogeneous stakeholders

[158]. This extended technology landscape and the need for an adaptive technology

framework was the main motivation for our proposed ISoS framework. The crescent

need from business stakeholders to plug networked business opportunities, requires

an open structuration for the underlying informatics and cyber-physical technology

landscape.

Our experience with the European MIELE research case centered on the

development of the Logistics Single Window (LSW) [6] and Port Community

System (PCS) [118] concepts has contributed to identifying constraining technology

dependencies. Furthermore, it was also possible to understand the perception of risks

of such inter-dependencies for achieving a sustainable answer regarding the

identified trend of collaborative logistics and transport models. Beyond costs, the

operational risks from failures, which are typically difficult to monitor and prevent,

pose a key challenge for such collaborative networks [42]. This studied case

identified the need for a novel strategy to promote collaboration among stakeholders

with diversity of sizes, processes, and technology concerns, as they were expressed

by the leading port authorities of Lisbon and Porto/Leixões (respectively, the APL


112

and the APDL). Supporting the large number of business messages varied formats

(e.g. GS1, EDIFACT, DATEX, etc.), requires specific investments in developing

adapters to enable establishing electronic business transactions to business partners.

The adoption of electronic interactions contributes to a growing involvement of

organizations (from small and medium to large enterprises) as nodes of such

Collaborative Networks (CN) in the mobility, transports, and logistics sector [146],

[8]. As an example, if a logistics service provider needs to collaborate with a new

logistics platform with different processes and technology systems, specific

adaptations are required. Consequently, beyond tackling the operational risks and

extra costs, such an approach requires specific adaptations, constraining the ability

to cope with the distributed collaboration processes [158]. These constraints are

related to the intrinsic complexity of dealing with specific software and technological

platforms. As suggested in [2], there is a need for a long-term cooperation agreement

and adoption of common principles and infrastructure as a basis for different

dynamic collaboration models. One important contribution to achieving a high-level

abstraction, is the ARCON that is a reference model for collaborative networks [28].

It defines three main dimensions: i) lifecycle management, ii) endogenous and

exogenous environmental perspectives, and iii) the intent, as the main axes for

defining a set of modeling abstractions, as it is developed within the European

project ECOLEAD [28], [29].

Our definition of ECoNet and its related concepts [159] use the ARCON

reference model as its base and provides a strategy to structure the involved

components under a unified coordination framework supporting complex

collaborative networks. The ARCON reference model for collaborative networks is

a contribution to the consolidation of collaborative networks as a growing

multidisciplinary scientific area [28]. Through ECoNet, we extend a key ARCON

concept, the virtual organizations breeding environment, to establish the ECoNet

framework and its infrastructure as the open bridge between endogenous and

exogenous interactions in the network. The design of the ECoNet framework and

infrastructure aims to establish a simple and generic strategy to logically connect

individual organizations under a common coordination framework.

The ECoNet, as an enabler for collaboration across organizations, follows a

strategy to capture business collaboration development and management, with a

three-dimensional view of: behavior, level, and facet. Just as well, the concept of

Business Collaboration Context Framework as proposed in [142] was followed.

Internal organization’s informatics systems need to be mediated by adapters to

access proprietary APIs to integrate such networks, as shown in Figure 32, through

dashed lines directly connecting ITsystems.


113

Figure 32 – Organizations manage uncoordinated point-to-point collaborations

The mediation typically requires specialized electronic data interchange software

that manages specific collaboration contexts, such as UN/EDIFACT for order and

invoicing electronic messages, DATEX for traffic information messages [119], and

SWIFT for banking messages.

Following the ARCON’s virtual organizations breeding environment concept,

our enterprise collaboration manager (ECoM) Isystem functions as the coordination

and operationalization responsibility for electronic interactions between

organizations. As such, ECoM is an implementation of the ARCON’s Collaboration

Layer (CL) concept, as discussed in [144]. The CL layer considers an adaptive suite

of services; each one tailored to manage a specific Collaboration Context (CoC). We

define a collaboration context as an application domain where two or more

organizations need to exchange electronic messages with a specific format and

coordination data, under a business objective. In fact, CoC embeds (abstracts) the

former integration adapters under a standardized framework, making existing

business platforms to promote a shift towards peer-to-peer or flat collaborative

relations, thus reducing business dependencies by adopting an open technology

strategy. Such an open framework adopts the ECoM nodes and establishes an

enterprise collaboration network (ECoNet) infrastructure. The ECoM is an Isystem

of the organization’s ISoS informatics systems landscape. ECoNet takes advantage

of the ISoS’s openness and its dynamic adaptability as a necessary condition to

answer the growing complexity of Collaborative Networks (CN) informatics

systems landscapes, thus constituting our ISoS-CN.


114

5.2 The enterprise collaborative network

The main objective for ECoNet is to establish a unified and trusted endpoint,

connecting organizations to a generic (standard) multi-tenant collaborative space.

Such spaces aim to support virtual organizations' breeding environment (VBE) with

a minimal preparation level to join (possibly in a dynamic way) new business

opportunities [4]. It is the responsibility of the ECoM component to coordinate such

participation by playing the adaptation/mediation role between the companies’

internal Isystems and the different collaboration contexts in which the organization

participates.

Therefore, the ECoNet infrastructure organizes around the following three main

components [159]:

• Enterprise Collaboration Manager (ECoM) – abstracts a composition of one

or more collaboration contexts, where ECoM = {CoC0, CoC1…CoCn}, for n

> 0. Any ECoM must have a system collaboration context that we identify as

the Collaboration Context zero (CoC0);

• Collaboration Context (CoC) – abstracts a specific collaboration and is made

of one or more collaboration context services (CCS), where CoC = {CCS0,

CCS1… CCSk}, for k > 0. The collaboration context service zero (CCS0) is a

mandatory (system) service and establishes the CoC entry point;

• Collaboration Context Service (CCS) – abstracts an atomic computational

responsibility that can be implemented based on the Cooperation Enabled

System/Services (CES) framework [145] presented and discussed in Chapter

4. The access to a CoC goes through the I0 entry point (mentioned above).

Furthermore, for simplicity, the CCS is a CES.

The ECoNet model evolved to incorporate the concept of Virtual Collaboration

Context (VCC) [159] as a strategy to manage multi-tenant groups, where

participating organizations can share a common virtual space, as discussed in section

5.2.2. A collaboration context CoC is itself a CES component, and as such the CCS

collaboration services are the CES services. Our strategy was to develop a model

that does not restrict potential specific technologies or technology strategies

following as little as possible an intrusive policy, and freeing the market to be

innovative. Here, by not being intrusive we mean that an ECoM informatics system

(Isystem) is a composite of Cooperation Enabled Systems/Services (CES), where

some of them are CoC after the CES specification. The initial idea of adopting a CCS

modular granularity is related to creating the potential for reusing collaboration

services among different collaboration contexts. However, from the market’s side,


115

the decrease in costs of computing, memory, and storage resources has made it favor

isolation of computational responsibilities as a strategy to benefit competitiveness.

Our defined ECoM is, therefore, an Isystem composed of specialized atomic

CES elements responsible for managing data and coordination exchanges under

specialized collaboration contexts. Figure 33 presents the main elements of the

ECoNet infrastructure, showing that interactions between the Isystems of different

organizations flow through the specialized ECoM Isystem.

Figure 33 – The main elements of the ECoNet infrastructure

The instantiation of an ECoM establishes a specialized ISoS landscape, which

we designate as ISoS collaborative network (ISoS-CN), meaning an organization

prepared for collaboration [30]. Figure 34 depicts the ECoM CoC element as a

specialization of CES with the additional collaborationContext attribute. Figure 34

also shows the ECoNet-CNO concept as a composite of one ECoM representing an

ECoNet member of the ECoNet Coordinator. Therefore, the ECoM is an Isystem

composed of one CES0, zero or more CES, and one or more collaboration context

(CoC).


116

Figure 34 – The ECoM Context Architecture

One of the CoCs is the ECoNet collaboration context, which is a kind of meta-

collaboration context responsible for maintaining the organization logically

connected to the ECoNet collaborative network. The MIELE case developed a

container tracking service as validation for message exchange between participating

stakeholders. The complexity of integrating legacy systems from each participating

stakeholder motivated the development of a collaborative application (Isystem),

enabling message and file sharing (ECoChat, later renamed to ECoMsgExchange).

The demonstration made possible the creation of multitenant virtual collaboration

contexts (VCC) restricted to invited organizations and authorized users.

The isolation of CES or CoC means that sharing functionalities inside CES or

CoC molecules (the services) goes through the CES interfaces. The separation

(independence) of collaboration contexts as (micro) services enables

implementations based on different technology frameworks. The adoption of

Isystem and CES granularity simplifies the instantiation of new collaboration

contexts with the introduction of the CoC as a specialization of a CES. The ISoS

systemic approach relegates the decisions about modularity abstractions to a

strategic level. The Isystem and CES establish the modularity while the service

concept is a decision for the CES/CoC (developer). In the specific case of ECoM

collaboration contexts, they follow the CES model, as discussed in more detail in the

next subchapter.

5.2.1 Enterprise collaboration manager

A Collaboration Context (CoC) is a set of services under a specific coordinated

choreography contributing to some specialized (business) collaboration. The

structure of services depends on the required mechanisms to answer specific

application message exchange needs. In the MIELE case, two main collaboration

contexts were considered: i) a container tracking service from freights managed by


117

the single logistic window, and ii) a collaboration service for a multitenant message

and file exchange. The validation/demonstrator considered messages and files

exchange collaboration services as a reference implementation for the CoC concept.

The CoC approach suggests that specific collaborations, e.g., the services provided

by the maritime authorities like TRAde Control and Expert System (TRACES),

Mediterranean AIS Regional Server (MARES), SafeSeaNet (SSN) develop their

collaboration contexts to be instantiated by stakeholders that need to interact with

them. As an open, collaborative framework, it is expected that a specific

collaboration context is available under a multivendor business model. As an

example, logistic companies like DHL can offer programmatic services under the

ECoNet framework instead of maintaining their proprietary interaction protocols and

services. Instead of adapting under a specific integration solution, a CoCDHL

collaboration context can be adopted for Isystems to dynamically integrate with DHL

business services (through CoCDHL-enhanced ECoM).

The ECoNet collaborative network effectively supported the MIELE case

middleware requirements offering an open specification for the logistics single

window (LSW) collaboration needs. The door-to-door multimodal freight transport

services and a container tracking service served as demonstration cases. The main

challenges were to integrate collaboration needs with enterprise systems (Isystems)

and to scale the growing number of collaboration partners.

The adoption of ECoNet requires deployment of an ECoM as an Isystem made

of a composition of one or more collaboration contexts. An ECoM is by default

composed by a collaboration context zero (or system/meta-collaboration context)

CoC0, responsible for the establishment of an ECoNet node. The interface I0

(service0) of such CoC0 has the responsibility to establish the ECoM trusted network

(the ECoNet VBE). In fact, since a CoC is a CES, the strategy to provide ECoNet

services follows the ISoS framework principles. What is important is that enterprise

Isystems see ECoM as an Isystem, a composite of CES where some are CoC, and at

least one is the CoC0. To make the model simple, the ECoM Isystem follows the

Isystem and extends CES to tag a collaboration context. Figure 36 depicts the SysML

model of the CoC concept, extending CES with the additional collaborationContext

attribute. An ECoM represented by a SysML Block is made of a CES0, zero or more

CES and one or more CoC as a specialization of CES. No additional models are

necessary to logically distinguish between CES and CoC as elements of the ECoM

Isystem.


118

Figure 35 – The Collaboration Context (CoC) as a specialization of a CES

Therefore, an organization wishing to adhere to the ECoNet should proceed in

following the joining process addressed below, in order to be a part of the ECoNet

VBE:

• Access an ECoNet registry directory provider:

o Register as a new ECoNet node by filling a registration form and by

exchanging trusted information (legal documentation from governmental

authorities may be needed).

o The newly registered node can make profiles private or public (modes:

secret, private, and public). Secret means no other organization has

access to the profile; private means restricted access to ECoNet VBE

members; and public means access without any restriction.

• Downloading an implementation of the ECoM Isystem or configure access

through an ECoNet service provider based on a cloud computing

infrastructure [122]:

o The basic infrastructure includes the CoC0 with the services for

establishing of the ECoNet VBE;

o The proposal assumes a marketplace of collaboration contexts

(CoC) to be available under some business model possible to


119

download from suppliers. As with the elements of the ISoS

framework, so the CoC is subject to conformity certification.

As proposed in [145], the aim of using collaboration services implemented as

CES entities (CoC as a specialization of CES) is to establish a dynamic, adaptable

informatics infrastructure independent of specific technology frameworks (.NET,

JEE, etc.). Nevertheless, as already discussed, and considering the underlying

complexity associated with the specificities of each collaboration context, the

ECoNet framework is not restricted to a specific implementation strategy. Moreover,

the standardization of collaboration contexts follows a similar approach proposed for

CES. The standardization can focus on specific semantics, providing the specific

meta-data and required interfaces {I1, …, In}. Therefore, the main objectives of the

adopted ECoNet infrastructure are the following:

• Provide integrated management and coordination of collaboration relation;

• A unified representation of specific collaboration contexts based on

collaboration context services (CCS), potentially modeled as CES services;

• An open marketplace for innovative collaboration contexts from a central

ECoNet coordination/management organization, e.g., accessible at domain

econet-cno.org.

The ECoNet infrastructure is itself managed by a root (central) registry Isystem

accessed through the specific collaboration context zero, CoC0 (see Figure 36). This

registry is responsible for maintaining the profiles of registered organizations, those

that are members of the ECoNet VBE. The ECoNet specification is founded on what

we can refer to as the ECoNet collaboration context (CoC0) standardization process.

Two main standardization processes are considered: i) the one establishing the

ECoNet core infrastructure, centered on the CoC0 of the ECoM Isystem, and ii) the

standardization of domain-specific applications with their collaboration context

(CoCi). These two main standardization lines are, in turn, grounded on the ISoS

standardization efforts, which are expected to be of general nature for any other

application domain.


120

Figure 36 – The Collaboration Contexts ECoNet, ECoMsgExchange, and LSW

Figure 36 depicts four primary validation collaboration contexts and their

respective Isystems that support the exchanging of data and control among them.

These four subsystems, as represented in the figure, are also briefly described below:

• ECoM Isystem - The ECoM Isystem, in respect to the ECoNet collaboration

context, is responsible for establishing the ECoNet breeding environment as a

trusted collaborative network (CoC0);

• ECoMsgExchange Isystem - This is a demo collaboration context validated

in the MIELE project enabling organization users to exchange messages,

develop conversations and meetings, and other specialized functionalities;

• Logistics Single Window (LSW) - This is the collaborative network

established by an implementation of the Logistics Single Window (LSW)

concept for transportation services considering integrated management of

door-to-door freights supported in the MIELE project by the container

tracking messages.

• Traffic Data Exchange (TDE) Isystem - This is proposed for the Exchange

of traffic messages using the DATEX standard and based on the management

of contractual commitments (agreed Service Level Agreements, SLA);

As depicted in Figure 37, the ECoNet node is modeled by an organization’s

profile including information about business areas, collection of identifications,

contacts and the organization’s address.


121

Figure 37 – The Organization concept modeling an ECoNet node (organization

profile)

Despite the completeness of the proposed models, the industry success of the

proposed framework depends on certain strategic key aspects including the

following:

• Being able to demonstrate a robust dependability strategy considering aspects

like security, reliability, scalability, and completeness against the specificities

of the business requirements that depend on specific business domains;

• Development and providing an execution model to cope with existing

processes and technology dynamics (achievements and innovations) from

communication and computer engineering to business modeling expectations

and strategies;

• Provision of an adaptive framework to accommodate novel process and

technology patterns, namely to be able to cope with the growing holistic

(systemic) complexity of approaches from sensors/actuators to business

intelligence services.

The developed demonstrations (ECoM with ECoNet collaboration context,

ECoMsgExchange, LSW managing container tracking messages, and Traffic Data

Exchange - TDE) helped with validating our initial design, and to obtain feedbacks

that constituted the basis for our further research towards an open collaboration

(technology agnostic) framework. In a technical workshop that was organized with

stakeholders, our approach was well-received; highlighting that the ECoNet

approach addresses the technology dependency problem and the growing difficulty


122

of integrating existing diversity. Furthermore, the impact of our strategy on the

market and how it addresses the current business expectations were discussed.

5.2.2 Virtual collaboration context

The collaboration context (CoC) plays a role similar to a specialized adapter for the

management of the exchanges of data between Isystems from different

organizations. The CoC establishes multi-tenant spaces for groups of ECoNet nodes

(partners) we identify as Virtual Collaboration Contexts (VCC). A VCC establishes

one or more groups (multi-tenant spaces) from the ECoNet ecosystem members able

to establish a restricted view which exclusively grants access to nodes that joined the

VCC. It is important to clarify that a VCC is to be managed by Isystems that access

one or more CoC to exchange business data with a peer Isystem (from a business

partner). The Isystem that creates a VCC, is its owner. An ECoNet node can join a

VCC after accepted by its owner. Bellow, formalizing this new concept, augments

the CoC with the enhanced virtual collaboration context (VCC):

▪ A Collaboration Context (CoCi) – abstracts one or more virtual collaboration

context services (VCC), where VCCi = {VCC0, VCC1, …, VCCm}, for m > 0,

is the set of the VCC of the collaboration context CoCi;

▪ A Collaboration Context (CoC) is, therefore (e.g., for the collaboration context

i):

o CoCi = CCSi ∪ VCCi; i.e., the set of all the CCS (if adopting this thinner

modularity organization) and VCC of the collaboration context CoCi;

▪ The Virtual Collaboration Context zero (VCC0) exists by default and includes

all the ECoNet nodes holding the same installed collaboration context; they

belong to the same business partnership.

The visibility of an ECoNet node is restricted to the peer ECoNet nodes that

accepted to be business partners (same business partnership). Each ECoM instance

maintains a list of the trusted ECoNet nodes to be business partners. Figure 38

depicts the SysML model in a collaboration context (CoC) as part of an ECoM, and

a composite of one or more virtual collaboration contexts and the corresponding

owner (the ECoNet node that created the VCC). The ECoM maintains a list of trusted

ECoNet members considered as business partners ready to collaborate under any of

the installed collaboration contexts.

An Isystem (a client of ECoM) can create new collaboration contexts and accept

joining requests from any of the business partners. This model enables the creation

of a multi-tenant subset of business partners to be used by Isystems to manage

interactions under specific collaboration constraints (isolation of other CoC


123

members). The virtual collaboration context can be the support for dynamic

arrangements of organizations establishing Virtual Enterprises (VE) [121].

Figure 38 – The Virtual Collaboration Context (VCC) concept

During the MIELE case, a collaborative Isystem, for the exchange of messages

and files, was developed to validate the virtual collaboration contexts, enabling

ECoNet members to manage a file or message exchange shared spaces. Figure 39

depicts a user’s interface view of a demonstration of available services that can be

used to create virtual collaboration contexts (VCC), for sharing messages or files

among the ECoNet joining members.

Figure 39 – A snapshot of the ECoMsgExchange ECoNet reference Isystem


124

From the ECoMsgExchange web interface, a user from the organization can

create and invite ECoNet members to join a VCC. Under a selected VCC, a user can

share files or messages. For both the ECoMsgExchange and PCS Isystems, presented

in the next chapter, two distinct specialized CoC were developed: i) the

CoCECoMsgExchange for the exchange of data in the context of the message exchange

demonstration, and ii) the CoCPCS for the exchanges between the Port Community

Isystem and other peer Isystems members of a same Virtual Collaboration Context

(VCC). The CoCPCS collaboration context was used by an Isystem (enterprise

application) for tracking a container of demo freight involving a set of participating

stakeholders.

5.3 Isystem in Collaborative Networks Context

Existing approaches to structure the Collaborative Networks landscape do not

answer the real problems that organizations are facing in coordinating the diversity

of electronic interactions involved in their heterogeneous Isystems. Most approaches

assume the mediation pattern, based on dedicated adapters or that the integration

systems must translate protocols and model the exchanged semantics. More recent

contributions adopt semantic mediation and web ontology as a generalization

strategy for sharing information models [86] and coordinating collaboration between

multiple business processes [15].

From the informatics science and engineering perspective, a collaborative

network establishes a directed graph of nodes and edges, where the nodes are

organizations with their business process and technology systems, and edges are

cooperation links between organization’s technology systems. The diversity of

technology adopted by each organization establishes multiple edges between two

nodes as a complex network of dedicated connections based on different protocols

and message formats. The grid community suggested that the grid infrastructure

should support the virtual organization paradigm as it shares “unique authentication,

authorization, resource, access, resource discovery, and other challenges”

requirements answered by the grid technology [60]. Such a hypothesis would have

to assume that all organizations adopt conforming implementations of the open grid

architecture. In the same article, an inter-grid protocols strategy is proposed for the

case in which a different implementation of such an open grid is adopted. However,

a virtual organization requires more than putting distributed workstations together to

share and interchange resources and computing based on earlier works like [1],

mentioned many years later in [59], and related to the virtual organization concept.


125

Despite efforts to establish a robust network infrastructure to support the emergent

collaborative network paradigm, one main recognized issue is the cost associated

with instantiating and maintaining the services. Even if the grid succeeds in the

scientific research domain as a de facto standard, the business world continues to be

dominated by ad hoc vertical-specific solutions that support collaboration.

Therefore, adopting a unified infrastructure, including its implementation (in the

form of systems or libraries), might not be the most effective path to follow. As an

example, consider the proposal of a Virtual Organization (VO) Management System

(VOMS) [112], where a KeyVOMS Server functions as a repository of services, a

KeyVOMS Virtual Organization Policy Enforcement Point (VO PEP), and a

KeyVOMS Client establishes a unified infrastructure capable of managing virtual

organizations. Nevertheless, to the best of our knowledge, no strategy is yet proposed

to promote competing business dynamics. One main problem is that no unified

approach can so far cope with all the requirements. Thus, each rendering potential

frameworks that are partially successful, and not an alternative to the most successful

proprietary approaches, that are e.g., SAP, Oracle, IBM, and Microsoft.

We approach the above challenge from an alternative perspective, and based on

the following main assumptions:

i. No unique technological approach can be the answer under a complete

suite of capabilities for the overall requirements, considering that real-

world undergoes continuous change;

o Development costs and operational risks raised to answer to

changes, are the primary concern;

ii. Informatics in a fast-changing paradigm and the endless innovation

pressure requires agile technologic solutions;

o What makes the standardization efforts led by industry, lacking

market competition;

iii. Any strategy should assume continuous change, diversity based on a

different interpretation of the problem domain, and market competition

as an advantage for costs moderation;

o The need for a third force to push for the minimal consensus on

addressing the concept of ecosystem, as coordinated

heterogeneous elements must cooperate as a system of systems;

iv. An organization has its own identity, its culture, competes with peers,

so it does not make sense to see such independent element accepting

evolve in a direction that blurs its integrity;


126

o Any model of a networked computational infrastructure should

establish common principles and force the market itself to push

for certain conforming solutions;

o The common conforming agreements should be as simple as

possible, to cope with the growing complexity resulting from a

generalized digital association among such organizational

structures.

Our proposed ISoS model applied to the Collaborative Networks domain abides

by the above assumptions, and is guided by the following principles:

i. Starting from communities and governments, include all end-

organizations to establish open specifications and to invest in

development of open reference implementations, free for the market to

adopt them;

o Create successful demonstrations and phased rollouts to help to

exhibit the associated value for end-organizations, as discussed

further in Chapter 6;

ii. Use of reference implementations as a strategy to consolidate or

achieve completeness for the specifications, at a structural and semantic

level;

o Adopting open source dynamics supported by end-

organizations, and by inducing the multi-supplier paradigm,

the approach contributes to sustainability by preserving fair

costs throughout its entire lifecycle management of complex

informatics infrastructures.

The ECoNet collaborative platform and the ISoS structuration for the enterprise

technology landscape is our proposal for managing the complex collaboration of

data/control exchanges between organizations. The ECoM is designed to serve as

the Isystem responsible for data and control exchange between the organizations.

The Isystem0 (through CES0) at each organization serves as the metadata repository

to access services of the organization, that are potentially based on different

technology frameworks. The ECoM is the specific Isystem, as part of the ISoS

technology landscape, responsible for the collaboration issues. Figure 40 outlines

two organizations adopting the ISoS framework, each one with its Isystem0 and

several other Isystems. One of these Isystems at each organization is an ECoM, with

its collaboration context (CoC) elements.


127

Figure 40 – The ECoNet as an Isystem of the open ISoS infrastructure

However, more important than the adoption of CES is the Isystem abstraction.

Any organization’s IT is based on a set of Isystems where the special Isystem0 is the

organization’s entry point to access common management services. An Isystem0 can

be standardized regardless of the CES concept. We argue that our approach is a

global hierarchical structuration based on the CES as atoms (supporting a thinner

granularity for strategic purposes) and Isystem as a composite of CES, where these

two concepts together guarantee the multi-supplier requirement.

It is important to note that the adoption of such an open infrastructure is a

challenging endeavor and requires more than a well-founded model. It requires a

paradigm shift about current market leadership. Large companies commonly invest

in a number of standardization processes to maintain or even increase their market

position. For instance, the example of Eclipse Foundation, originating from IBM, is

a de facto important initiative adopted by other large companies to converge the

development culture on a common framework and tools space, e.g., Oracle, TIBCO,

and SAP. Nevertheless, and while important, standardization efforts are a commonly

partial contribution to the problem and are naturally pushed by market interests.

In the next subchapter, we discuss our development and deployment tools,

frameworks, and execution environments, that argue in favor of a unified approach

for these cases, and presents important contributions until an open standard


128

modularity framework is provided and adopted by the software (Isystems)

development industry.

5.3.1 ECoM as Isystem of ISoS framework

The ECoNet infrastructure and collaboration coordination system is a main

research component for the development of the ISoS concepts. In our developed

validation case, ECoNet registry maintains a root entity with trusted ECoNet

organizations. Any ECoNet registered organization has a certified ECoM instance

with the ECoNet collaboration context installed.

The same applies to the other organizations involved in our developed

validation scenario. It represents the responsibility of each Isystem0 from any of the

involved organizations (access organization domain at default port 2058, the address

being econet-cno.org:2058), as depicted in Figure 41.

• At econet-cno.org:2058, the Isystem0 and within, the CES0, and the

service (I0) are accessed to obtain initial information about the available

CES0’ services. The ECoM is one of those Isystems;

o The CES is expected to support different implementations of

this service depending on the adopted models and technology

options;

• After obtaining the ECoM endpoint (at econet-cno.org:<dynamic-

assigned port>) and with the correct credentials, the CES0 and the

service (I0) are accessed to obtain the reference for the ECoNet

collaboration context, in order to access the implemented services;

o The collaboration context provides the data exchange

mechanisms; it plays an adapter role.

It is noteworthy that, to a certain extent, a collaboration context is not in fact

necessary if accessing the target Isystem through the Isystem0 of the peer

organization. Nevertheless, we suggest, as a principle, to collaborate through the

ECoM, in order to maintain virtual collaboration contexts, thus establishing multi-

tenant logical spaces shared by the members of a specific group of organizations.

Furthermore, through the ECoM Isystem, the organization can manage collaboration

policies, namely the decision to create, join, or leave specific virtual groups (or

organizations).

The ECoNet strategy does not require an ISoS organization. The ECoM Isystem

can be deployed and accessed directly. Furthermore, the ISoS can be gradually

adopted by wrapping legacy systems and promoting the integration with the ISoS

framework. Under the ISoS model, the Isystems of an organization interact through


129

an ECoM instance as depicted in Figure 41 for the MIELE case of port

administrations of Lisbon and Porto/Leixões (APL and APDL). An ECoM instance

is configured with the necessary collaboration contexts (CoC), following the ISoS

(Isystem and CES) modeling concepts.

Figure 41 – A global perspective of ECoNet platform under the ISoS model

The proposed model might lead to complex and dependent solutions if not

associated with semantics standardization processes. By semantics standardization

processes, we mean the establishment of common data models, services, and

coordination mechanisms to promote competing products. Such standards are

adopted to guarantee that more than one supplier has an alternative offer, and the

substitutability principle applies, e.g., ontologies for specific application domains.

As an example, the DATEX standardization process beyond the message

(payload) formats also develops transport layer mechanisms, establishing messages

exchange under security issues. The standardization process can be significantly

simplified if the DATEX specification only addresses the semantics and structure of

messages. The adaptive ISoS framework, based on the CES atoms and services as

molecules, is flexible enough even to accommodate different communication

protocols, e.g., depending on communication constraints. In a real-time setup, it


130

might be necessary to adopt an efficient binary data exchange protocol. The ECoNet

is further founded on the communication infrastructure module (PCI), which was

based on an adaptive communication infrastructure with the selection of the

appropriate communication links and protocols depending on communication

requirements (message size, minimal latencies, cost, and other attributes) [27].

5.3.1.1 The open adaptive coupling infrastructure

Every interaction between CES components occurs under an adaptive mechanism

based on the mandatory service zero (I0) implemented by the SelfAwareness()

method. Through this service, any CES negotiates the capabilities (through the

implemented services {I1… In}) based on metadata. A supplier can enable CES with

different implementations based on different technology frameworks and execution

environments. Instead of the current Enterprise Service Bus (ESB) [34] concept

based on adaptation responsibilities, and in most of the cases evolving towards

dependent informatics system (integration broker/hub) with the vendor-lock-in

problem [140], this thesis establishes the CES adaptable dependency resolution

mechanism identified by the Open Adaptive Coupling Infrastructure (OACI) [120].

A CES can play a mediation role, e.g. when necessary to Extract, Transform,

Load (ETL) data from a legacy system [14]. The CES concepts can wrap mediation

with a legacy system as a strategy to promote the reutilization of existing assets and,

at the same time, evolve towards a less dependent informatics infrastructure.

5.4 Development Strategy and Validation Methodology

The potential success of ISoS depends on the end-organizations; those organizations

that suppliers of informatics systems are potentially interested in their investments.

If end-organizations invest in adopting ISoS, it is the opportunity for them to evolve

for an agnostic technology landscape. Such investment is a strategic move for the

end-organizations as buyers to include ISoS requirements in their acquisitions

process and impose its technical specifications to be adopted by the market. The

larger the buyer end-organization, the more is the influence to promote disruption in

market practices. Depending on the established granularity for the required Isystems,

the risks decrease with the proposed approaches, thus new market opportunities are

created to new players. Nevertheless, other semantics-related issues and problem

domain specificities need to be addressed by the standardization efforts. Even if two

suppliers develop an Isystem for the same issue (application domain) based on the

ISoS framework, the substitutability is only guaranteed if the new Isystem can

recover the operational state and the historical data under a complete and automatic


131

migration process. Our validation scenarios for the open modularity of

computational responsibilities, demonstrate the feasibility and main contributions of

our approach in the cases of ETC, SINCRO, and HORUS. However, given the

complexity of Isystems, the substitutability is so far still limited to the CES level.

Moreover, from our partial results these three cases and a more recent case of

MOBICS project [155] we can report that our proposed model and approach is being

well adopted and applicable to industry requirements and needs under a smooth

approach. The Mobility Intelligent Cooperative Systems (MOBICS) Isystem [155],

developed in the context of the European SCOOP@F Part 2 project as a contribution

of Brisa Innovation and Technology company and the participation of ISEL as a

research partner, is another example of such approach.

Despite research results, the main problem is the lack of a de facto

understanding, concerning the necessary investments to realize such an open

framework. Empirical evidence demonstrates the difficulty for decision-makers to

invest in experiments (science and technology research) and to validate valuable and

potential approaches. The need for investment without guaranteed results (in a

research context) and the pressure from the market to sell its views, grounded on

well-recognized brands and getting advantage from promised faster innovation

realizations, make the long-running strategies challenging to be adopted by the

market. We argue, based on the research cases, that ISoS is a strategy to grasp the

control of current IT technology landscapes, rendering it “governed” under a

common framework.

To overcome the weakness of the bridge between the risks associated with

science and technology research, and the adoption of ready/existing

products/solutions, we have developed a Collaborative Enterprise Development

Environment (CEDE) what provides a complementary strategy to help to converge

for open complex Isystems [149].

5.4.1 The Collaborative enterprise development environment (CEDE)

The vendor-agnostic research conducted to the definition of an Open System of

systems in a slightly different approach, while similar in its objectives to the well-

known Open System Interconnection (OSI) [9], developed for the

network/communication layer. The most challenging goal is to achieve a systemic

informatics approach, based on a composite of Isystems and CES where each

subsystem is expected to guarantee the substitutability principle. The definition of

open Isystem of systems (ISoS) diverges from what the industry usually presents as

open systems, centered on its promptness in integrating with any existing or legacy

system. As a principle, any Isystem is (or should be) developed under architectural


132

concerns on how to decompose the system into subsystems, guided by an internal

reutilization strategy. A complex Isystem product follows such a modularity strategy

under the culture of the developing company. This application of engineering best

practices is classified as internal modularity, considering that such division of

responsibilities is internal to the technology developing company. Two system

architects inevitably arrive at a different distribution of responsibilities (modularity

framework), unless the same reference architecture is followed [120]. In the open

Isystem of Isystem formulation, each subsystem should be considered under external

modularity, meaning that it implements open (standard/public domain) interfaces.

The design of such a SoS under external modularity, requires the architecture to

derive from a reference architecture, and being compliant with the open

specifications. Our research took the challenge of developing an equivalent open

Isystem, where the end-organization has more power over it with enhanced control

of an Isystem. Figure 42 depicts the vision of a transition from closed to open

Isystems, where an open Isystem has elements from multiple suppliers and a leading

responsibility independent from the supplier. The open Isystem considers elements

with two or more suppliers and a move from single to multiple responsibilities.

Despite the different structuration of the new open Isystem, it needs to maintain

equivalence in relation to the legacy closed Isystem. The Open Isystem is considered

under an open governance model since it is led by the end-organization and the

owner of the Isystem, since dependency is then reduced by promoting the

multivendor paradigm.

Figure 42– From a closed to an open Isystem


133

Our approach starts from a high-level strategic vision to address the upcoming

complex Isystems where the existing dependencies are not acceptable considering

they lock-in innovation processes to unique suppliers. We adopted the Model-Driven

Engineering Open Systems (MDEOS) initiative to frame the CEDE platform,

previous research on the Cooperation Enabled System (CES) [145], and the ISoS

framework [120], into one common comprehensive covering. The mdeos.org,

registered as an Internet domain, supports logical address to prototype

demonstrations, e.g. HORUS.mdeos.org, mobics.mdeos.org, etc., as well as a logic

Web address to get services, e.g. the cede.mdeos.org to access the CEDE reference

implementation.

The MDEOS depicted in Figure 43 is a program grouping projects under the

same development and operations “culture” to promote the adoption of CES as the

external modularity framework for the development of open Isystems. The strategy

assumes the complexity of substitutability and the need for standardization.

Confidence of the industry (user-organizations) investing in the adoption of our

reference architectures, open specifications, and reference implementations is of

paramount importance for consolidating the ISoS approach.

Figure 43 – The Model Driven Open Systems strategy

The MDEOS-covering initiative relies on the existing gap between processes

and technology that needs to be shortened, and if possible, removed from the

establishment of a suite of coordinated model-driven tools. The ISoS framework and

the CES modularity abstraction are contributions for reducing the gap between

processes and technology. Although the core contribution of our research center on


134

the technology layer, the proposed modularity abstractions provide the coupling

mechanisms, for simplifying the technology bindings of business processes.

This gap between processes and technology domains is a long-running research

topic [123]. From empirical requirements and knowledge originated in our studied

and discussed real cases, we have identified that designing a reference

implementation is complex to achieve for two main reasons, i) the lack of

completeness of requirements, and ii) the diversity of evolving models and

technologies. These constraints make it difficult for the market to follow open

standard Isystems making them substitutable products.

Both CEDE and ISoS, with Isystem and CES, are research contributions aiming

at reducing the gap between processes and technology. Thus, the ISoS research is a

contribution to an open modularity framework. The ISoS is further a strategy to

evolve an organization’s technology landscapes towards the substitutability

principle. The next section details aspects of the CEDE development platform.

5.4.1.1 The CEDE platform

CEDE is a platform for development of open complex, large-scale Isystem of

systems grounded on an enhanced collaborative ecosystem. CEDE founds on the

following basis simple principles: i) an open and unified culture established by the

suite of adopted concepts, implementations, technologies, methodologies, tools, and

techniques; ii) a realization through a CEDE server with a reference implementation;

and iii) competencies and certification process both for developers and for

companies. One main objective consists in establishing a vendor-neutral Isystem

development culture, thus reducing the tacit knowledge that is common to software

development processes. For this purpose, and as a knowledge-intensive activity,

many strategies were researched, namely the adoption of a robust transitive memory

system (TMS) to support the knowledge sharing among software development teams

[196].

A CEDE implementation has been adopted by the A-to-Be company (a Brisa

Innovation and Technology brand) that has assessed and used our research

prototypes. Meanwhile, CEDE keeps evolving, based on the selection of

methodologies, technologies, and tools, aiming to incrementally establish a more

comprehensive standard development and deployment environment. A more long-

term objective of our research is to extend the CEDE platform to also contribute to

other lines of our identified gap with an enhanced version, offering a universal design

framework and tools for the process domain, as a strategy to reduce processes in

technology systems bindings. The idea is to provide two main groups of specialized

tools, one for technology developments and the other for accessing process experts


135

to perform the required agile adaptation to requirements changes, as depicted in

Figure 43. The second line of tools is tackled under the model driver design and

engineering research, e.g., the adoption of process-oriented developments based on

the BPMN standard [129].

The following options were considered mandatory for an initial version of the

CEDE platform: i) the projects are structured based on the Apache Maven

framework using Git version control and Nexus repository management; ii) the

Eclipse integrated development environment unifies the tools, namely a tight

coordination with the Maven mechanisms (through M2E plugin); iii) The Java

language and the OSGi specification were selected as mandatory approaches; iv) the

Redmine22 issues and project management tool was selected as the main contributor

to establishing a collaborative development environment, eventually enhanced

through specialized plug-ins, and v) a federated authentication and authoring

infrastructure based on a Lightweight Directory Access Protocol (LDAP) directory

unifies the access control.

The openness requirement as well as being recognized as de-facto standard by

both the industry and research community, guided the selection of our technology

paradigms and tools. For the potential question, of the reason behind the adoption of

OSGi, and no other (software level) modularity framework, relies on its intrinsic

potential and recognition based on a growing adoption by the industry. Even if the

OSGi modularity specification depends on Java, there are research works evaluating

the possibility of binding this framework to other programming languages, e.g., C#

and .NET as discussed in [98]. Following similar founded decisions, the

development of the CEDE platform adopts the Linux server Ubuntu, and it is planned

to be deployed from a reference implementation able to accelerate adoption. The

CEDE servers might be running on-premises or in the cloud, as a dedicated resource,

to manage and coordinate collaborative developments for complex, large-scale

Isystems.

The selection of specific frameworks or computing paradigms is challenging to

decide when there are more than one with strong, valuable arguments. One extreme

example of such decision difficulties is the adoption by the OSGi standardization of

two competing paradigms: i) the Blueprint Container (osgi.121, BC) and the

Declarative Services (osgi.112, DS) as frameworks realizing the dependency

injection and inversion of control patterns (DI/IoC). While being argued for the

structuration of large-scale object-oriented applications [143], the OSGi standard

22 Redmine - http://www.redmine.org/


136

seems, however, to be conditioned by industry investments. Even if the Declarative

Services (DS) paradigm is gaining momentum, any product developed on Blueprint

Container also conforms to the standard. The duplication of standards is an example

of the extreme constraint to converge on a consensus of deciding on single

approaches when many options have their arguments.

It is important to note that the followed research strategy has been evolving for

a framework where technology diversity is not a problem. The agnostic approach

means that the CEDE initiative is a tacit approach rather than an end. The ISoS

framework, while guided by a technology agnostic, is the anchor for pushing for

substitutable computational responsibilities, standardized under open reference

models such as a reference implementations project. Like other research

contributions, the main challenge for ISoS is the introduced meta-efforts leading to

extra costs, an aspect which is not easy to understand since results (value) take time

to assess. In the Brisa case, from the research started in 2002, measurable results

were reported in 2008, valued around 186 million EUR [70]. The research results

would consider the contribution from other research lines, even if the reduction of

vendor lock-in issues was considered a main reason for the created value.

Furthermore, the tacit knowledge associated with the software development

process is not only a problem for IT product development companies but also for

end-organizations. The lack of standard off-the-shelf Isystems results in need for

specific developments as the current and most usual strategy to make capabilities

fully match the requirements. The end-users (companies, public organizations, and

authorities) have many difficulties in establishing competitive tenders for IT

capabilities, based on the discussed risks of dependencies they might induce. The

public tenders usually specify what is required but not how the capabilities should

be organized, making the budgeting very difficult and the resulting system dependent

on the culture of the awarded supplier. These aspects are the main reasons to

pretermit start-ups and small and medium companies (SME) in favor of a larger, less

risky and well-known Isystems suppliers with its own culture.

Therefore, beyond the pragmatic suite of principles, the CEDE platform

establishes an open IT development culture. It aims to contribute to an enhanced

open competitive market, thus easing the path for start-ups to prove the capabilities

of their products. The CEDE platform considers that subcontracted development

teams share a common development workbench with coordinated on-premises or in

the cloud instances, as depicted in Figure 44. The risks are reduced based on the

substitutability principle resulting from the adoption of the CEDE IT development

unified culture. A first approach to the CEDE platform was adopted for the

development and deployment of the ECoNet [159] and HORUS cases. HORUS has


137

the participation of two start-ups (Exploitsys and Makewise), a large IT supplier for

the POS subsystem (Gasodata/Dresser Wayne) and two large end-users’ companies

(Galp and BP), making the case well-suited for initial validation.

Figure 44 – A possible CEDE layout involving organization and Cloud

To summarize, the CEDE platform is founded on a suite of well-known tools with

the main entrance portal from where collaborating companies and individual

developers can have access to perform their contributions. The main modules of

CEDE platform include: i) a single sign-on and authorization module, based on

LDAP and federated identity management); ii) a project and issues management tool

(based on open-source Redmine); iii) a repository management (based on Nexus)

and Git versioning system; and other governance, documentation, and management

tools, as depicted in Figure 45. The CEDE is a unified development portal for

collaborative developers to access project, repository, monitoring, lifecycle,

administration, wiki, quality auditing, and reporting management services under a

single user sign-in and authorization facility.


138

Figure 45 – The CEDE unified collaborative development environment

Furthermore, the CEDE platform aims to establish an open, collaborative

development and deployment space, answering the immediate difficulty of getting

an effective multi-supplier (open) modularity framework. For large complex

Isystems, it is not realistic to achieve the substitutability principle for the whole

system. Our approach enables the reduction of dependency risks for the development

of specific Isystem’s elements by facilitating the substitution of the developing

subcontracted development team.

We, therefore, address the difficulty that large informatics systems development

companies face to manage their subcontracted partners through the specific

developments. The Brisa/BIT case was the initial motivation for the CEDE platform

to establish a unified development environment and therefore improve the

reutilization of already developed elements. It is not easy for the development

manager to push for reutilization strategies when the subcontracted companies hold

different process and development cultures. Large companies commonly can impose

their own development culture on networked partners. Those models have the

drawback of establishing proprietary solutions. Furthermore, convergence is

expected for a hierarchical market structure, where larger companies have positioned

themselves as integrators, responsible for Isystem of systems that is based on a

network of smaller specialized companies as suppliers of CES elements or Isystems.

The CEDE research tackle these challenges and contribute to an open approach with

equivalent, if not better, performance to the already existing market approach that is

based on proprietary cultures.

5.5 Summary

139

5.5 Summary

This chapter presents and discusses the adoption of ISoS as a structure for Isystems

in a collaborative network. The fast-evolving dependencies of business relations

from digital interchanges establish a complex collaborative process that needs to be

managed and maintained in a complex web of heterogeneous informatics systems.

The ECoNet collaborative infrastructure is presented and discussed, considering the

ISoS framework, as presented and discussed in Chapter 4. The ECoNet platform is

made of ECoM network nodes configured with collaboration context (CoC) and

virtual collaboration contexts (VCC). ECoNet provides an alternative to the current

bilateral and specific business data interchanges agreements. These interchanges

based on dedicated adapters make the growing number of interdependencies among

organizations challenging to maintain and evolve. The CoC entity is a structured

approach to manage specifics semantics associated with collaborations in different

application domains. The ECoNet formalization enables an organization to

dynamically create or join a business network, thus establishing a new business

(scientific, social) collaboration. Consequently, the ECoNet framework, as far as

application domains are concerned, is a context-free framework. It can support

virtual collaboration contexts in the different application domains.

Furthermore, the ECoNet platform presents a validation for the complete ISoS

framework. It is a contribution to the structuration of the organization’s informatics

systems under a cooperative community, discussing a dynamic integration

mechanism based on the I0 (SelfAwareness() method). It is a contribution to

disrupting the current organization’s automation islands and an alternative to the

enterprise integration bus (ESB) potential recognized as contributing to technology

dependencies (vendor lock-in problem).

The unification of development environments based on the Collaborative

Enterprise Development Environment (CEDE) platform is presented and discussed

as a strategy to overcome the difficulty to standardize the organization’s Isystems.

The existing and growing open source world has generated new development tools,

languages, protocols, and frameworks. However, these open dynamics are a

contribution to specific technology artifacts also establishing dependencies. The

CEDE open development framework (or workbench) is part of the more global

strategy, the Model-Driven Open Systems (MDEOS), targeted to reduce the gap

between processes and technology. The MDEOS is like an umbrella covering the

initiative for the Isystem of systems (ISoS) integration strategy based on the Open

Adaptive Coupling Infrastructure (OACI) and other related initiatives (projects), like

the ECoNet collaborative network platform.

141

Chapter 6

6 Research and Development

Results Validation

Our research targets the study of complexity involved in providing open, integrated,

and coordinated underlying computing technology artifacts for process automation,

both in a single organization and in networked organizations. In Chapters 3 and 4,

we propose and discuss an initial approach based on ITSIBus, the open Isystem of

systems (ISoS.0 and ISoS) frameworks. In Chapter 5, we extend our framework into

ISoS-CN, to support the integration strategy for organizations and unifying

collaborative networks interactions with the ECoNet platform and framework.

Primarily, the lack of a commonly accepted definition for openness of systems and

the system of systems has conditioned our results, and has caused the constraining

and challenging our achievement of system substitutability goal.

In most cases, the word “open” is used to classify approaches, solutions, or

systems, where in many cases openness does not imply having a substantiated

capability for the system, to promote market competitiveness and enabling the multi-

supplier paradigm. A common applied approach consists of offering the capability

to interoperate with other systems, through an open interface (API). Our main

research contribution is to provide a framework that can support diverse

implemented APIs that are developed based on diverse technology paradigms, and

framed (unified) through an adaptive services framework. Our proposed open

Informatics System of Systems (ISoS), discussed in Chapter 4, establishes an open

and adaptive system integration framework as a strategy for adopting competing

implementations and software products, that are developed for the same

computational or cyber-physical responsibility, thus providing an adaptive

modularity framework.

The following publications partially present and discuss relevant aspects of our

achieved results:

Chapter 6. Research and Development Results Validation

142

• A. Luis Osorio, Luis Camarinha-Matos, Tiago Dias, and Jose Tavares. Adaptive

Integration of IoT with Informatics Systems for Collaborative Industry: the

SITL-IoT Case. Springer International Publishing, 2019.

• A. Luis Osorio, Luis Camarinha-Matos, Hamideh Afsarmanesh, and Adam

Belloum. On Reliable Collaborative Multimodal Services. Springer


• Joao M. F. Calado and A. Luis Osorio. Dynamic Integration of Mould Industry

Analytics and Design Forecasting, pages 649–657. Springer International

Publishing, 2017.

• A. Luis Osorio and Rui Oliveira. Sistema nacional de controlo de velocidade

(sincro). In Seventh Portuguese Road Congress (7 Congresso Rodoviario

Portugues - Centro Rodoviario Portugues - CRP), 2013.

• A. Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh. Cooperation

enabled systems for collaborative networks. In Adaptation and Value

Creating Collaborative Networks, volume 362 of IFIP Advances in Information

and Communication Technology, pages 400–409. Springer Boston, 2011.

10.1007/978-3-642-23330-2_44.

• J. Sales Gomes, Gastao Jacquet, Miguel Machado, A. Luis Osorio, Carlos

Goncalves, and Manuel Barata. An open integration bus for efc: The its-ibus.

In ASECAP conference. ASECAP-2003, 18 - 21 May 2003 in Portoroz, Slovenia,

May 2003.

This chapter addresses four specific industry cases that we have studied and

developed as validation proofs of our approach, namely ETC, HORUS, SINCRO

and MIELE. We argue that substitutability, as defined in section 4.2.2.6, is the main

challenge to achieve an effective open system, where multiple competing

implementations can be adopted. Although, our achieved results and measurable

metrics are mostly applied to low-level infrastructural domains or cyber-physical

elements, our formalized approach can also be extrapolated for higher levels of

informatics systems. This aspect is also partially demonstrated by a number of

industry cases, that adopted our strategies to maintain openness who invested in our

research and development efforts. The Brisa concessionaire reported cost reduction

through introducing competing suppliers for tolling road systems [69]. Another

example is the cost reduction experienced by the Portuguese international speed

enforcement tender in July 2014 following the SINCRO research project. The

winning bidder offered cinemometers for about half of its expected cost [145], [120].

The HORUS project also demonstrated the advantages of following a multi-supplier

approach, in this case enabling the plugging of two products that implemented

6.1 Multi-Supplier Induced Value

143

license plate recognition for automatic identification of vehicles in a forecourt. A

number of further research in the agro-industry and multimodal mobility also

indicates adopting the proposed framework towards agnostic informatics systems

technology setups based on the ISoS framework [154], [26], [152]. It is also

noteworthy that the role of industry decision-makers is paramount in contributing to

R&D investments in developing a market-independent technology integration

strategy [153].

In this chapter, we present and discuss our achieved results, while also pointing

out the constraints and drawbacks of the proposed models. Beyond the results

obtained in our research, the discussion of difficulties related to adapting open

systems for business strategies, complement the concerns for motivating agile

technology solutions. Even if centered on technical aspects, our approach also

considers dealing with real case challenges. The adopted cases have made it possible

to identify relevant strategic and business issues by learning from the partner’s

expertise in their addressed process application domains.

This chapter is organized into five main sections: Section 6.1 describes the

introduced value associated with the multi-supplier paradigm, which resulted from

the proposed models and methodology. Section 6.2 presents three validation cases,

namely the Electronic Toll Collection, the national speed enforcement SINCRO, the

HORUS payment control in forecourts, and the MIELE case. Section 6.3 presents

and discusses the model and methodology for large complex tenders preceded by a

technology validation phase. Section 6.4 rationalizes the value gained from open

innovation dynamics, centered on the development of open specifications. Finally,

section 6.5 presents the summary.


Our research proposes a holistic strategy towards the development of agnostic ISoS,

even assuming that some systems might have been consolidated partially at the lower

layers e.g. in cyber-physical systems. This research develops evaluation prototypes

and acquires validation from the participating stakeholders responsible for both the

electronic toll collection (ETC) and the speed enforcement use cases (SINCRO). In

the Transports and Logistics case (MIELE), the exchange of business messages was

also considered, under specific business cases that simulated stakeholder’s

production systems. This in turn led to our common constraint of extrapolating

demonstrators to be as close as possible to a production system. Therefore, primarily

we lay out the validation of the ISoS approach for toll and speed enforcement

applications, including the discussion of weaknesses and strong points. In the


144

following subsection, we discuss use cases considering simulations or extrapolated

results by comparing the approaches at higher levels of enterprise informatics

systems with infrastructure level cyber-physical systems, e.g., the RSE in the

electronic tolling (ETC) or cinemometers for the vehicle speed-enforcement network

(SINCRO specifications). Figure 46 depicts a general ISoS perspective, positioning

our approach in offering an independent technology framework. The idea of

Platform Independent Models (PIM) can be effective with the ISoS framework

where substitutable Isystems contribute to the execution of Computational

Independent Models (CIM) and managing of the access to Platform Specific Models

(PSM) under specific technology independence.

Figure 46 – The ISoS contribution to abstracting Specific Technologies

Independence

To measure added value of the ISoS framework, we primarily consider the

platform-specific level, i.e., the productization has made it possible to measure

valuable results generated by our approach. However, it is important to frame the

contributions in other levels and perspectives as well and in relation to our proposed

holistic approach to the organization’s technology landscape integration. Often, in

practice the real implementations differs from the planned models. These differences

that are mostly due to the need for in-time decisions, based on the evaluation of

unplanned situations, require taking immediate solutions, in order to guarantee the

satisfaction of business contracts. However, the reduction of such gap between the

planed models and the specificities of the implementations can be effectively

supported by adopting our proposed framework based on the Isystem, CES, and

Service concepts. If taken as a reference implementation, the technology specificities

will be hidden into the Service, concept and accessed through the unified adaptive

OACI mechanism.


145

The ISoS framework is also a contribution to the lack of potentially dynamic

mechanisms to adapt models, under some “refactoring” process at the development

time and keeping them updated regarding any needed change. In Chapter 5, we

present a strategy for the case of transport and logistics single window. By adopting

ISoS Isystem and CES-delimited computational responsibilities, the technology

infrastructure can be programmatically introspected to identify implemented

services, thus obtaining implemented capabilities matching the business process

requirements. Modeling tools can be developed to manage Isystem libraries and

obtain access to implemented capabilities and binding business processes, activities

as a strategy for tightening model-driven development approaches.

Theoretically and from the demonstrated changes at the lower layers, the

proposed and demonstrated approach received a generalized acceptance both by the

scientific community and by the industry cases, and resulted in their continuation of

investment in our R&D efforts. Although for lower-level system integration, our

approach demonstrated costs reduction effectively, we recognize that for higher-

level layers of organization’s business processes automation, it is not as easy to

establish clear, complete and standardized computational responsibilities, when

establishing both substitutable CES elements and Isystems conforming to a reference

model. However, from the value earnings e.g. costs deduction by the induction of

market competition, the need to establish semantics standards and open reference

Isystem as specialized computational responsibilities, is demonstrated by validation

cases, for the construction of a competing modularity technology landscape based

on the ISoS framework.

6.2 Validation Cases

Our experimental validations, through demonstrators, pilots, and deployments, have

developed during several years, under a solid partnership with private and public

industrial organizations. Our selection of cases also demonstrates the developed

models and methodology, including transports and mobility of persons or the move

of good, and the collaborative networks and related areas as road safety and petrol

distribution network. Other experiences under partial approaches involve partnership

with colleagues from other scientific areas as a strategy to consolidate our required

holistic approach through telecommunications, video analytics, electronics, and

mechanical engineering.

These are the selected cases to validate the contribution towards ISoS, that

include:


146

• The case of the Electronic Toll Collection at Brisa concessionaire

(ETC);

• The Petrol Distribution Forecourt HORUS Isystem (HORUS);

• The case of the National Speed Enforcement Network (SINCRO);

• Logistics and transport in ports Logistics Single Window (MIELE).

The challenge to establish an open architecture for agnostic ISoS is the common

scientific research target for all these cases. The level of validation is different for

each case, ranging from identifying success indicators from the industrial partners to

achieve recognition by the research community, through scientific publications, as

well as acquiring market acceptance by resulting costs reduction. This last

achievement was through introducing market competition for the same

computational or cyber-physical responsibility. Nevertheless, continuous investment

from the stakeholders is a clear indication of their interest in the ISoS framework.

They expect and observe valuable contributions from our research work, even if the

adopted results are mostly partial. The CEDE platform in [149] and discussed in

Chapter 5 partially answers the concerns discussed by the Software Engineering

Method and Theory (SEMAT) initiative. It aims to help to validating and

consolidating solid scientific foundations for the upcoming complex Isystem of

systems development [85], [131]. By taking into consideration the challenge to

establish a closure for unified standard Isystems, the CEDE unified development

environment aims to improve such convergence and at the same time reduce

technology dependency risks.

6.2.1 Implementation of ETC case at Brisa concessionaire

The vendor lock-in dependency is one of the fundamental issues of our research (See

Research question, Section 1.4). The Intelligent Transport Systems Interoperability

Bus (ITSIBus) model is a first result that could be measured by the reduction of costs

at the acquisition of systems [151], [150], [69], [148], [157] and Chapter 3. As

discussed so far, the service-oriented approach to the Electronic Toll Collection

(ETC) infrastructure of the Brisa concessionaire resulted in several new acquisitions,

representing cost reductions from the adoption of the ITSIBus strategy. This came

from the possibility of adopting products from competing suppliers. Since its initial

deployment at the beginning of the nineties, the ETC Isystem was based on a

monolithic solution supplied, from sensor elements up to the central (back office)

systems at the clearing company Via-Verde, by a single responsibility of only one

company (the ETC-supplier). Any change to answer technology updates or to satisfy

new requirements had to be subcontracted to that unique company. In 2001, the Brisa


147

concessionaire started a new business by offering a new payment service based on

the OBU (Via Verde transponder) to access parking lots and fueling at Galp’s petrol

stations, the largest Portuguese petrol company, The consortium named Access also

included the Portuguese bank Caixa Geral de Depósitos (CGD), the Portuguese main

public bank. However, even though it was an interesting, innovative business model;

its application turned out to be complex and costly.

In the same year, Brisa created the Innovation Department to work on the

development of a strategy to rethink technology and business strategies to help the

group improve the quality of existing infrastructures and services and to be prepared

to lead technology strategies for new business in Portugal and abroad. The initial

formulation of the ITSIBus resulted from a research project granted by Brisa and of

the responsibility of Instituto Superior de Engenharia de Lisboa (ISEL), a Lisbon

Polytechnic Institute (IPL).

The adoption of the ITSIBus model made possible a second supplier offering

the critical Road Side Equipment (RSE) responsible for identifying the vehicles

crossing a Via Verde tolled lane. Because of this flexibility in selecting the supplier,

the cost of an RSE went down one-third of its initial cost. The reduction was a

demonstration that for closed, monolithic solutions without competing alternatives

in the market, the costs are conditioned by the supplier’s strategy. While not

imperative, the adoption of a service-oriented architecture played a facilitator role

that resulted in a simplified abstraction for the differences of the two RSE

subsystems. It is worth to note that standardization was beyond programmatic

interfaces. It was also necessary to unify physical fixtures, power supply voltage,

and electrical plugging elements.

The ITSIBus model has also contributed to the simplification of the interaction

between the RSE and the Lane Management System (LMS). The ITSIBus approach

helped to hide the specific implementations of the CEN/TC-278 and the European

EN-12834 standard adopted by each supplier considering different options for the

application layer of the Dedicated Short-Range Communication (DSRC) vehicle

identification system. One identified issue consisted of dealing with varying

strategies of implementation of existing standards, e.g., the adoption of a different

IP port number, TCP/IP or a higher HTTP protocol for the interactions. Most

standards adopted by embedded (or cyber-physical) systems follow the Open

Systems Interconnection (OSI) classic layering of abstractions from physical radio

frequency and analogic signals to the application layer. However, application layers

establish, in many cases, different strategies for communication protocols, data

payload formats, or even specific TCP/IP ports (low-level interactions definitions).


148

Figure 47 represents a Brisa’s perspective of the ITSIBus service integration bus,

showing how ETC elements interact through our proposed service bus.

Figure 47 – The ITSIBus architecture as adopted by Brisa company

A cyber-physical RSE system is a paradigmatic example of the difficulty of

establishing the substitutability principle. Despite the number of standardization

efforts at the application layer (under the OSI model), the physical fixing

mechanisms, the different power supply voltage, and physical plug formats,

commonly not considered. Even for the application layer, the adoption of HTTP

communication based on an embedded web server introduces obstacles for advanced

dynamic adaptability of such cyber-physical systems under a substitutability

principle. Our approach to the vendor lock-in problem succeeds because of the

willingness shown by Brisa to invite multiple suppliers to converge towards common

specifications under a holistic and coordinated approach involving mechanics,

electrical, electronics, and informatics, knowledge domains under a collaborative

consensus converging for unified specifications.

Nevertheless, because of the complexity of the real-world problems we are

dealing with, it is difficult to integrate all the variables in a well-founded scientific

model, considering that it requires a multidisciplinary approach. One important

learned lesson was that the construction of the emergent ISoS requires sustainable

multidisciplinary research and development efforts. By sustainable, in this context,

we mean the need for a common understanding of how difficult it is to implement


149

the changes needed for the industry to converge towards “plug-and-play” products

based on adaptive mechanisms. The emergence of the cyber-physical systems as

elements of complex distributed Isystem requires the rethinking of borderlines

between computer science and other science and engineering areas in a balanced

approach between industry and end-organizations interests. There is a need to

promote coordinated changes from different disciplines as shown in the

(re)construction of the Electronic Toll Collection (ETC) system of systems case

where multiple domain competencies were needed ranging from mechanical,

electrical and computer science and engineering. The ITSIBus and the evolving ISoS

have adopted, as the main concern, simple adaptability of legacy systems and

different development cultures. We consider such simple adaptability as a

sustainable strategy for the involvement of both industry, end-organizations and

research efforts under extended multidisciplinary collaborations for developing an

open complex integrated system of systems (the proposed ISoS framework).

6.2.2 Implementation of petrol distribution forecourt case HORUS

Isystem

The HORUS system developed in the context of a research grant for the Portuguese

petrol company Galp through its Galpgeste subsidiary started in 2007 in a

partnership with ISEL. In 2013, as a result of a Galpgeste initiative within APETRO

(The Portuguese Association of Petroleum Companies), BP Portugal, undertook a

research grant with the Research Association POLITEC&ID (ISEL/IPL). The

sponsoring of the project under APETRO aimed, besides sharing R&D and

development costs, to ensure the HORUS system conditions when fueling any

vehicle with outstanding payment (i.e. an incidence) in any service area of any

distribution petrol company.

The project was committed to challenging an integrated technology solution

(strategy) for the payment enforcement system identified already in production at

Galp, without being integrated with other related systems. A security services

company developed an independent and isolated system based on manual

maintenance of a database with license plates of vehicles that left the forecourt

without undertaking fueling payment. The deployed Isystem demonstrated to be

inefficient since the Point of Sales (POS) operator had to check manually in another

system if a vehicle to be fueled had any pending payment. The legacy system was

supposed to play a sound when any vehicle with a license plate into the database

enters the fueling area. In observed cases, the POS operator did not hear the sound

from the legacy system. Furthermore, it was difficult for the POS operator to

associate the vehicle with the license plate into the database within the pump


150

requesting authorization for fueling. In several cases, vehicles with its license plates

in the database (payment incidents) were not identified by the POS operator and

therefore recurrently proceeded to fuel with no corresponding payment.

To answer the problem, we developed an open architecture, to automatically

control the post-payments in a forecourt (petrol station). The payment enforcement

automates the maintenance of incident data elements with information from each

vehicle that leaves the forecourt without payment. An incident data element includes

the license plate, information about the missing payment and other relevant data,

with the unique purpose of automating and helping the POS operator on deciding

about a fuelling authorization. Video cameras and an automatic vehicle license plate

recognition (LPR) system identify vehicles approaching a pump (dispenser) to be

fueled. When the driver gets the nozzle from the dispenser, the POS is warned and

automatically communicates to the HORUS Isystem, querying for the existence of a

pending incident associated with the vehicle. Depending on the answer from the

HORUS Isystem, the POS console shows one of three possible signs: green, red, or

orange, meaning respectively, without pending payment, unidentified situation, or

vehicle with pending payment. The unidentified situation (orange icon) means that

the HORUS Isystem couldn’t identify the vehicle because some communication

problem has occurred, an obstacle prevented the camera from accessing the license

plate, or any other vehicle identification or incident verification failure.

In the HORUS project, we adopted the International Forecourts Standards

Forum (IFSF) “vision” of a multi-supplier forecourt. Our approach considered a

high-level logical Petrol Distribution Open Service Bus (PDOSBus) as a strategy to

promote agile and adaptive cooperation among forecourt Isystems (or elements). The

prototypes and pilots have involved the Gasodata Company, a subsidiary of the USA

Dresser Wayne Corporation to validate the integration of the legacy POS. The

cooperation interface between the HORUS and POS the user interface of the POS

systems are open specifications expected to be adopted by other potential suppliers

of forecourt payment systems. It is worth noting the need for a change in the POS

user interface. Depending on the decision of HORUS Isystem about the existence of

an incident associated with a dispenser requesting authorization for fueling, the POS

operator sees an icon according to the explained situation. Even though our research

focuses on the openness of the computational landscape, the real cases present many

more variables challenging to address under a well-founded model.

6.2.2.1 The HORUS technology architecture

The HORUS Isystem has a central back-office aspect and a suite of distributed

components running in the forecourt, as depicted in Figure 48. Both the forecourt


151

and back-office integrate with other Isystems through the PDOSBus as the concept

responsible for the open specifications and contribute to promoting multi-supplier

informatics systems following the IFSF23 multi-supplier principles. This

communication shares a secure communication infrastructure based on a Virtual

Private Network, a secure connection based on a Transport Layer Security / Secure

Sockets Layer, or other equivalent technology.

The Refueling Payment Supervision (RPS) module assumes the coordination of

the cooperation with the POS payment systems. When a new vehicle owner removes

the nozzle from the dispenser, the RPS is queried by the POS on the existence of an

incident related to the served vehicle. The RPS module coordinates with the Vehicle

and License Plate Recognition (VLPR) associated with the dispenser concerning the

identification of the vehicle using the collected license plate to query the local cache

database for an incident. The VLPR module is responsible for inspecting a sequence

of video frames to look for the vehicle’s license plate, submitting the selected image

to one or more License Plate Recognition (LPR) engines. The VLPR makes the best

effort to automatically and accurately identify any vehicle positioned to fueling to

be ready to answer a POS authorization request.

Figure 48 – General Architecture of the HORUS Isystem/solution

For operations without incidents, after the vehicle owner has paid at the POS

station, a communication is made by the POS to the RPS module to clear all the

23 IFSF - International Forecourt Standards Forum


152

information on the vehicle (the data element that is ready to be promoted to an

incident if no payment occurs). However, after a parameterized timeout variable, if

the POS does not return a payment done message (for the identified transaction), the

RPS module generates an incident that will be managed by the Local Incident Data

Management System (LIDMS) module. The incidents are maintained locally by the

LIDMS in coordination with the Central Incident Data Management System

component, responsible for spreading new incidents among all the forecourts of the

operator's distribution network.

The Point-of-Sale was adapted to integrate to HORUS Isystem under two main

dimensions: i) the communication link to HORUS, and ii) the improvement of the

POS user interface to inform the operators about the existence or not of an incident.

As already mentioned, when the HORUS system reports an incident related to a

vehicle, a red symbol is presented to the POS user. If no incident exists related to the

vehicle, the POS user is presented with a green symbol. Otherwise, if no

communication exists or the HORUS system could not obtain the vehicle

identification, the user will see an orange icon. Both the

computational/communication and user interfaces of the POS system are part of the

logical integration bus identified above as the Petrol Distribution Open Service Bus

(PDOSBus).

As established in the project, we have extended the concept of Bus to

accommodate any standardization effort aiming to contribute to a change in the

supplier side towards technology unification, processes, and presentation language.

The idea is to promote new products or updates on existing products that must be

prepared to cooperate with the HORUS Isystem under open or standard interfaces.

The standardization contributions range from communication, computational,

physical/mechanical, electrical to user interfaces. So far, the PDOSBus considers

aspects related to the design of the computational, communication, and user

interfaces for the cooperation between HORUS and the POS, and between the POS

and the forecourt operators (users). The project identified related research

challenges, namely the definition of a virtual execution environment where a micro-

data center unifies the currently used and isolated bare-metal (hardware) servers. A

complementary project sponsored by BP, the On-premise Virtualization dot Cloud

(OPV.Cloud) is proposed to promote a unified bare-metal (physical) computational

infrastructure common to all computational requirements in a forecourt. As a first

evaluation, the two physical servers to support HORUS and the surveyance CCTV

servers are being evaluated to be replaced by a unique server in virtualization

infrastructure.


153

6.2.2.2 The HORUS development strategy

To validate the HORUS design, we developed a demonstrator and later a set of pilots

to validate the assumptions and fine-tuned approaches. In 2010, we developed a pilot

in the Galp network, and with adherence from BP to the project, a few pilots were

developed to validate improvements and to consider new variables related to the

specificities of the BP forecourt network. The pilots were of the responsibility of the

GIATSI research group and later had the collaboration of the Exploitsys IT company

created in 2012 by two former researchers involved in the HORUS project.

As an important result, the Exploitsys start-up was subcontracted in 2015, by

BP to deploy and support the HORUS system (HORUS roll-out process at BP). The

POLITEC&ID research association maintains the multi-supplier research challenge

and the commitment to converge implementation for the ISoS framework. The

tensions between the suppliers under the adopted model is difficult to manage. Our

strategy considers maintaining clear independence between the deployed version and

an evolving version used to validate new models and in our specific case, the

adoption (productization) of the ISoS open framework.

Another result was the adoption of the Plate-Vision license plate recognition

product from the Makewise IT company (Portugal) as an alternative to the Carmen

product from ARH (Hungary). As a research partner of the GIATSI research group

since 2002, Makewise is motivated (they became suppliers of BP) to take part in the

technology partnership to help the development and the validation of the openness

perspective of HORUS Isystem. The coordination of contributions from these

companies uses the Collaborative Enterprise Development Environment (CEDE)

established with the endeavor to unify the development culture based on a pre-

established selection of technologies, languages, frameworks, patterns, processes,

methodologies, and tools. The objective is that both Galp, and BP maintain the

opportunity to choose the technology partner to support the HORUS solution against

a suite of potential candidates certified on CEDE and that way prepared to offer

support services (responsibility).

The CEDE unified development platform complements the Model-Driven

Engineering Open Systems (MDEOS) vision while contributing to the integrated

lifecycle management of complex Integrated Isystems. MDEOS follows the Model

Driven Architecture (MDA) vision [186] established by the Object Management

Group (OMG). An example is the retail information system based on the Resource-

Event Agent (REA) business ontology approach [194]. Our approach considers a

coordinated reutilization of existing standards or standardization efforts associated

with the adoption of a suite of tools and technology patterns under open source


154

initiatives. Such a bounded environment aims to impose a sufficient and versioned

environment to support HORUS productization and its life cycle development

(support and evolution) with the contributions from the participating companies.

6.2.2.3 The Collaboration among petrol distribution companies

The collaboration among petroleum distribution companies is planned to adopt the

Enterprise Collaboration Network (ECoNet) platform. The ECoNet platform [146],

[159], and Chapter 5 aim to model the actual assortment of specialized adapters for

business-to-business data exchanges by providing a unified and coordinated business

message exchange infrastructure for organizations. The plan is to establish a

subscription for pending incidents (data elements with information about a lack of

payment in a forecourt) through the specific CoCHORUS collaboration context that is

accessed by the organization’s Isystems through an adaptive open coupling

infrastructure (AOCI), a kind of enterprise service bus.

The Collaboration Context (CoC), CoCHORUS can model a specialized adapter

necessary to share incidents in a forecourt, as depicted in Figure 49.

Figure 49 – Adoption of an ECoNet specialized CoCHORUS Collaboration Context

To exchange business data in any format (EDIFACT, DATEX, GS1, HL7, etc.),

an organization registers in the ECoNet network and installs an Enterprise

Collaboration Manager (ECoM), depicted in Figure 50. The ECoM Isystem

maintains a set of collaboration contexts coordinated by a special one, the

Collaboration Context Zero (CoC0), responsible for registering other collaboration

contexts and managing access to them through other organization’s Isystems.


155

Figure 50 – The exchange of business data through the ECoM Isystem

Incident sharing among petrol companies requires the authorization of the

national data protection authority, the Comissão Nacional de Proteção de Dados

(CNPD) in Portugal. It is a significant challenge necessary to outstrip by explaining

and demonstrating that the incident data elements are safely accessed (without

violating privacy) for the sole purpose of verifying a pending payment in any

HORUS enabled forecourt. In any case, the adoption of a demonstrated and validated

solution will depend on the authorization of CNPD (for the Portuguese example).

6.2.2.4 Remarks about the HORUS validation process

The HORUS project has demonstrated the feasibility and accuracy of an open

Informatics system to manage forecourt payments enforcement. The underway

productization phase is being consolidated by the adoption of a simplified

(preliminary) version of the CEDE development platform, as a strategy to guarantee

the multi-supplier perspective for both the support/evolution of the overall solution

(HORUS Isystem) and some of its components, e.g. the license plate recognition

component. The fact that two small companies were subcontracted by BP Portugal

to support HORUS, the Exploytsys, and the adoption of an alternative license plate

recognition computing element as an alternative (substitutability) to the Carmen

product is an important result. It is worth noting the investment of BP in R&D to

promote multi-supplier technology solutions, thus delegating the responsibility of

production systems and the supplying of components to small and young companies.


156

6.2.3 Implementation case of National Speed Enforcement Network

(SINCRO)

The Portuguese national speed-enforcement network (SINCRO) research project

was established in 2010 in a partnership between the National Road Safety Authority

(ANSR) and ISEL, to develop an open architecture and technology specifications for

a national network of speed enforcement sites. The project was of the responsibility

of the GIATSI technology and systems applied research group, which was also

responsible since 2002 for the foundation of the Brisa’s Open Research laboratory.

The SINCRO project, while not adopting the CES model in all its extension,

follows the formulated principles by defining open interfaces designed and

developed with the collaboration of potential suppliers. The time frame to validate

the specifications conditioned the decision to make mandatory the unification of

implementations in the project. However, specifications can evolve for the adoption

of the ISoS framework without the need for complex changes from the potential

suppliers of cinemometers or cabinets.

The project answered the need to write a vendor-agnostic tender considering it

followed several phases (about ten) based on partial tenders for the construction of

the national speed enforcement network. The lack of standards for a national speed-

enforcement network was expected to create a dependency from the winner of the

first phase by locking it for the remaining phases (lock-in vendor risk). To overcome

this problem, from 2010 onwards, the SINCRO specifications were developed based

on previous contributions from the Spanish Dirección General de Tráfico (DGT).

The work involved suppliers of cinemometer (radar) systems and informatics

solutions for the management of enforcement infrastructure. In 2014, the tender

based on the SINCRO specifications was published, and the winning consortium

started developing the first phase of the enforcement network.

State of the art identified existing information and technology for speed-

enforcement based on integrated proprietary systems. A traffic speed enforcement

system is a composite of IT and electro-technical (e.g., the cinemometer and the

cabinet) systems. The same supplier or integrator offers the suite of components

based on its strategy and specifications, establishing how they organize and integrate.

At the national level, the adoption of radar systems (the cinemometer and the

infrastructural components necessary for its operation) from different suppliers

required more than one central system (back office) or the need for a suite of adapters,

in a number closed to the diversity of adopted radar systems (from different

suppliers). Figure 51 shows the case of three suppliers for the radar/cabinet and


157

central systems (suppliers A, B, and C), where supplier A is responsible for the

required adapter and, in the other case, supplier C answers for the adapter.

Figure 51 – State of the market before the SINCRO standards

The difficulties in integrating informatics and cyber-physical systems make us

expect that such heterogeneous country-level solution will be difficult and costly to

develop, maintain, and evolve. The multi-supplier problem, the need for open

specifications, and the willingness (vision) of the president of ANSR public authority

made the national speed-enforcement network SINCRO project successful in

achieving a multi-supplier strategy in collaboration with potential suppliers.

The SINCRO project has established, as a primary strategic goal, the adoption

of the multi-supplier paradigm for the upcoming phase of the acquisition process for

the Portuguese enforcement-speed network, the SINCRO network. Figure 52 depicts

the vision of the SINCRO project where cinemometers, and cabinets from different

suppliers do not need the adoption of adapters to interoperate.


158

Figure 52 – After SINCRO open specifications (towards standards)

Based on the requirement, a cabinet might not have any cinemometer installed.

The number of cinemometers was planned to be less than cabinets, requiring they

needed to decouple from the cinemometer (the market model used considers

cinemometer and cabinet as a single unit). Therefore, the SINCRO approach

aggregates the following potentially multi-supplier components:

• The cabinet – physical metal cabinet that supports the plug of a radar

system from any supplier, to evolve as a CES element;

• The cinemometer – suite of components (radar system) potentially

from any supplier, to be modeled as a CES element; and

• The central Isystem (BackOffice) – subsystem responsible for the

collection of traffic events, processing them and delivering for the

Isystem in ANSR liable for processing contraventions for vehicles that

exceed the regulated speed in an LCV (Local Speed Control point).

In the following sections, we present and discuss the SINCRO specifications

and architecture, followed by the discussion of difficulties in developing agnostic

informatics systems. Finally, a discussion of the advantages of forcing suppliers to

comply with the specifications is also presented and discussed.

6.2.3.1 The SINCRO open specifications

The SINCRO architecture is established based on an initial evaluation of the state-

of-the-art and the agreement from the Spanish DGT to reuse the specifications

developed for the Spanish Enforcement network. Figure 53 depicts the general

architecture of SINCRO with its main elements. The local enforcement site (LCV)

is a road infrastructure based on the cabinet that can hold a cinemometer system with


159

two main logical connection buses. A data bus for traffic events and LCV

configuration commands, and the monitoring interface for the communication of

exception events (tentative to access cabinet, excessive temperature, unexpected

movement of the cabinet, etc.). The monitoring infrastructure aims to support the

maintenance view potentially based on an automatic quality of service management

(monitoring and maintenance subsystem).

Figure 53 – SINCRO general architecture

The traffic events, all or only those captured from vehicles exceeding the speed

limit, are collected by the Traffic Events Management System (SIGET) subsystem

and pre-processed by authorized operators and validated by the police authority. The

SIGET sends the events that effectively generate a contravention to the SCoT (speed

contraventions management system) subsystem through a specialized interface of

the ANSR open services bus (ANSR-OSB). In a possible evolution, the SIGET as

an Isystem can dynamically lookup for the SCoT Isystem service for contraventions

communication.

6.2.3.2 The open interfaces established by SINCRO

The SINCRO open specifications consider three main parts (Figure 54 gives a

detailed view of the main interface classes):

• The cabinet

o The physical dimensions, including the massif and fixing

screws; electrical interfaces, etc.


160

o A removable case to hold the radar system (cinemometer and

parts);

o The monitoring interface based on the Single Network

Management Protocol (SNMP) and the specialized Master

Information Base (MIB) data model.

• The cinemometer (radar subsystem)

o The computational programmatic interface for the exchange of

traffic events (the speed violation evidence) with the SIGET

subsystem;

o The monitoring interface based on SNMP protocol;

o A standard fix-structure plugs the cinemometer into the

cabinet.

• The Traffic Events Management System (SIGET) subsystem

o Collection and validation at the central office of the speed

events and delivery of infringing events to the SCoT

subsystem;

o Configuration procedures (e.g., the configuration of the speed

limit)

o Generation of reports;

Figure 54 – A detailed view of the SINCRO open interfaces

The SIGET subsystem aimed to validate specifications implementing the

required functionalities for the management of LCV events. After finishing the

research phase, the SIGET prototype was productized, maintained, and evolved

under the support contract of a company. To guarantee the independence from a


161

unique services company, the open development platform Collaborative Enterprise

Development Environment (CEDE) was adopted as proposed in [149] and Chapter

5. The main objective was to contribute towards the exposure of knowledge

associated with the lifecycle management of SIGET and assure that any CEDE-

certified company can assume maintenance and evolution for itself.

The developed specifications in the SINCRO project, extended from existing

preliminary specifications from the Spanish DGT traffic Authority, were shared with

the potential suppliers under a Request for Information (RFI), published at the ANSR

website, inviting suppliers to comment and contribute. The international tender

included a final version of the SINCRO open specifications, giving the potential

winner two years to obtain the conformity certification for both the cabinet and the

radar subsystems (cinemometers). The project further identified the need to promote

a standardization thread for traffic enforcement system under some European or

International Standardization body. Beyond the establishment of a multi-supplier

enforcement network, the induced market competition has contributed to reaching

cost reductions in the order of half of the average market cost, e.g., the case of the

reduction of the cinemometer cyber-physical system.

6.2.3.3 Conformity validation of SINCRO specifications

One crucial aspect of the SINCRO specifications is the conformity validation of

products. A radar system to be operated by police authorities needs to receive a

metrological certification (renewed periodically) from the Instituto Português de

Qualidade (IPQ), the national institute for quality and a conformity certification

from ANSR. A SINCRO certification workbench was developed to support the

conformity phase of the approval process. The SINCRO workbench executes a suite

of certification procedures to validate the interfaces of products, both the radar

system (cinemometer) and the cabinet. A Conformity/Certification workbench was

developed to help and automate the validation of the compliance products

concerning the SINCRO specifications. Figure 55 depicts a user interface of the

workbench prototype with the configuration and execution of tests to certify a

cinemometer. The user interface refers to the certification of Process Details,

including the date of the process, proponent, brand, and model of the product, and

approval code from the national metrology certification authority (IPQ). The address

of the company submitting the process, an automatically generated ID from ANSR,

and a public key referent to the certificate of the equipment guarantee law-court

value for the registered speed enforcement evidence [32].


162

Figure 55 – A view from the SINCRO conformity verification/certification

workbench

The conformity process might need further validation not yet addressed by any

certification process. One situation that needs attention concerns the multi-lane

feature. The cinemometer equipment evolved to offer the capability to register events

with the identification of the lane where the vehicle is running. The majority of the

existing road enforcement equipment support at least three lanes. Nevertheless,

metrics to evaluate the quality of the registration of vehicles under speed limits are

lacking. It is expected that a standardization initiative, under some workgroup of

some standardization body (e.g., CEN), is developed to consolidate the

specifications and promote the publication of SINCRO specifications under an

official standard.

6.2.3.4 Validation remarks about SINCRO

The convergence for the ISoS contributed to a unitary cost of the cinemometer

subsystem about half the market price, taking as reference previous acquisitions.

Despite the tender having maintained the requirement for an integral offer of

cinemometer subsystems, cabinets, and support and maintenance services, it was

possible to identify a clear trend for reduction of costs, and in particular, the

reduction of the cost of the cinemometer from the winning bidder. Nevertheless,


163

further research is needed to formalize a novel approach to the tenders. These are

usually developed based on what is required, commonly without a clear

technological strategy, and sometimes influenced by specific market approaches.

Tenders frequently lack a clear technology strategy guiding how the solution should

develop to avoid technology dependencies. The development of complex Isystem

requiring (integrated) Isystem of systems landscapes, result in strong dependencies

since implementation commonly depends on the technology (and processes) culture

of the tender winner. In the case of the SINCRO Isystem, to keep the SIGET

reference implementation up-to-date, reflecting requirements change, the project

suggested the adoption of the CEDE platform concept to help upcoming tenders

extend the network, making ANSR free to bid for the best financial offer.

6.2.4 Implementation of Logistics and transport MIELE case

More recently, the research endeavor evolved to the transport and logistics domain,

extending to collaborative logistics and supply chain management centered on ports.

The research endeavor establishes a trust framework for agents’ trustworthy data

exchange [38]. Transport and logistics form an application domain where the need

for collaboration exists for an extended period, and the perception of something new

to answer the fast-growing electronic business dynamics is the basis for a successful

business. The logistics single window concept, developed in the context of the

MIELE research case [146], establishes an open research field. In the MIELE

project, we proposed a Collaborative Middleware Infrastructure ECoNet (Enterprise

Collaborative Network)24. It was grounded on PEPPOL/OASIS Busdox

specifications [16], [160], (see Chapter 5) as a step further to structure the discussed

complexity to integrate legacy Isystems and the diversity of communication

infrastructures, protocols, and metadata and data models. The ECoNet platform is

based on the CIPA/eDelivery reference implementation, the official reference

implementation under OpenPEPPOL responsibility, led by the Directorate-General

for Informatics (DIGIT). The alternative reference implementation under OXALIS

project supported by the Norwegian Public organization DIFI, a Public Agency for

the Management and eGovernment, has incorporated the AS2 protocol used between

Portuguese and Italian vertical pilots. The developed models and demonstrators

proved the need for extra joint efforts and the promotion of consensus (towards

standards) to establish a European interoperability (collaborative) strategy.

24 www.econet-cno.org


164

The Portuguese MIELE Middleware National Pilot proposed to extend the

existing Port Single Window (PSW), in the port of Lisbon25 and the port of Leixoes26,

with the newly enhanced Port Community Services (PCS) platform for the managing

of Business to Business (B2B) and Business to Administration (B2A) exchanges.

The strategy for such a PCS wrapping the existing Port Single Window (PSW) is

founded on recognizing that the Logistics Single Window (LSW) pilot

Isystem/application, offering multimodal freight services, needs an initial validation

step led by port authorities.

The proposal had to address the difficulties to validate the ECoNet platform as

the reference MIELE Middleware (MMW) interoperability infrastructure, so as to

make stakeholders adopt ECoNet for their exchange business and coordination, even

if ECoNet adopts the emergent e-Freight messaging standards [67]. The e-Freight

has received generalized attention, namely efforts to evolve existing platforms in

order to answer fast and real collaborative needs, e.g., the identified evolution of the

PORTIS port platform [105]. Nevertheless, the complexity to integrate critical

legacy systems requires a stepwise approach to induce a smooth but firm change

towards an automated collaboration.

The followed strategy considered the development of PCS as a demonstration-

enhanced service provider to the existing JUP/PSW. The objective was to streamline

the validation of the proposed ECoNet platform and to isolate the integration with

the JUP Isystem in production. Figure 56 depicts two Isystems (ITsystem and PCS)

that interact through the ECoM Isystem with Isystems from partner organizations.

The strategy also suggested developing an enhanced pilot with the stakeholders that

participated in the MIELE project using a bridge wrapper (adapter) for integrating

intra-organization legacy Isystems for the ECoNet collaborative platform.

25 Port of Lisbon Administration - APL

26 Port of Leixões and Douro River - APDL


165

Figure 56 – The proposed convergence strategy for the existing JUP/PSW

The developed prototypes validated business message exchanges between

stakeholders operating in the Port of Lisbon. However, such validation is not enough

as it developed under ideal and controlled conditions, without involving

stakeholder’s legacy informatics systems in production. Nevertheless, the strategy

was recognized by the stakeholders as a valuable and riskless approach to validate

the proposed models under real scenarios. The network effect [173] of a platform

like ECoNet and its generalized adoption as an organization’s platform requires the

adherence of the market needs to prove itself. The ECoNet platform is planned to

develop under open specifications and open source initiatives. As discussed in

Chapter 7, such general adoption requires further research to find a consensus on

how to get, for the collaborative networks, a similar unicity such as the one for

communication network infrastructures.

6.2.4.1 Validation remarks about the Single Window concept

At the infrastructure level, it is easier to promote open specifications, while for

higher enterprise levels, the Isystems (usually referred to as back-office Isystems)

are much challenging to evolve for an open Isystem of systems (ISoS). One main

problem is the required semantics unification among a diversity of knowledge and

practice domains. The completeness of the existing models and specifications are far

to be a complete match, able to address the problems integrated lifecycle

management of (intra and inter-organizational) Isystems of systems. In the e-Freight

domain, existing monolithic proprietary and centralized systems can only evolve into

a sustainable collaborative network if some entity with regulation power promotes

open architecture and specifications validated through reference implementations,


166

thus leading to conformity workbenches, in the same way as it was demonstrated in

the SINCRO and HORUS cases.

6.3 Model and Methodology for Large Complex Tenders

The MIELE research case proposed a methodology establishing the procedures for

the development of the tenders for complex informatics systems. The methodology

is grounded on the lack of a complete set of standards able to formulate an agnostic

informatics system. The SINCRO case was the first project to validate the proposed

steps of the methodology, as depicted in Figure 57, which, as already mentioned, has

resulted a 50% reduced costs for the radar subsystem (cinemometer and related

components), [156]. The methodology has been evolving to fine-tune the adoption

of the ISoS framework by moving from the PIM to PSM strategy, to adopt the ISoS

modularity framework based on the Isystem, CES, and Service concepts.

Furthermore, the SITL-IoT project started in July 2018, in a partnership with the

FORDESI company, that follow the proposed approach and adopts the ISoS

framework in order to evolve the SDL silos agro-food industry for an open

technology landscape [154].

Figure 57 – Methodology for the development of complex ISoS

Our proposed methodology considers five main phases, as indicated in the

center of Figure 57. Some of the phases might be repeated (refinements) along the

lifecycle, if and when necessary. The developed informatics solution and the

underlying specification are expected to generate open (market competitive)


167

Informatics systems. These stages consider the following main activities and

produce their planned results:

• PIM definition – maps business, functional and non-functional

requirements to a set of independent technology models;

o It involves modeling and simulation activities, able to

consolidate the understanding of requirements. There is a trend

to render some models executable to improve validation and

reduce the risk of a potential gap between modeling

abstractions and the real systems.

• PIM to PSM strategy definition and validation – based on the defined

business processes and the required business objects, an effort made

towards the decomposition of computational responsibilities. The

architecture design and evaluation enable the consolidation of bounded

subsystems able to be certified against effective implementation of the

specifications. A reference implementation plays a key role as it should

be used to resolve misinterpretations of both specifications and the

requirements;

o Business processes and data object definition considering the

adoption of existing standards. The defined business objects

embedded into message payload during message exchange or

sharing;

o Technology architecture design considers the best effort to

adopt a subsystem product approach by making an integrated

IT solution as much as possible independent from a single IT

supplier.

• Promotion of subsystems as products – The service-oriented

architecture paradigm suggests well-defined loose-coupled service

providers as autonomous computational entities that publish and

discover for the implemented services. It is a paradigm that applies to

new mechanisms and modeling strategies able to define such a provider

in a way that can be implemented using any available or new

technology. While it is tentative to establish such a generic definition

for a computational responsibility, this seems to be partial, otherwise,

they will not be technology agnostic as it is the case of the Service

Component Architecture (SCA) proposed by OASIS with technology

bindings like web services, C++, and EJB open specifications. While

possible to include subsystems developed in other technologies, no

Microsoft technology binding is known;


168

o Open architecture design is essential as a step to promote

modularity, helping to achieve a market-competitive IT

solution (an open IT solution);

o It is an opportunity to exercise and effectively contribute to the

SOA paradigm by promoting autonomous computational

responsibilities following external “common look” (standard

interfaces) for the client (cooperative) subsystems.

• Validation prototype – Considering the need to “force” consensus

among market suppliers while naturally trying to get competitiveness

by differentiation, the reference implementations play a key role. The

“power” currently sitting on the technology providers (on the market),

as they make things happen efficiently with their technology strategies,

needs to be shifted to the end-users. The research partners on behalf of

end-users are responsible for the adoption of the best technology

strategies. These are not necessarily the most updated but rather the

best consensus possible to validate commitment of initial requirements;

o The development of the tender technical specifications is

important to establish a business interest for the participating

companies. The suggestion is to shift the competitiveness for

the costs and less for the confidence of a potential tender

winner. Dependency on the confidence of the potential tender

happens when the technical specifications are more focused on

“what” is required and less on “how” to approach the required

IT solution;

o The mechanism of a Request for Information (RFI) is important

to incorporate as much as possible the practitioner (IT market)

knowledge into the development of open specifications.

Furthermore, such involvement of potential competing

companies and even new start-ups are expected to evolve faster

to effective implementations, concurrently with the

maintenance of open specifications, preferably discussed in

specialized work-groups of targeted normalization bodies.

• Tendering process for individual subsystems and composite

integrated IT solution – this step is either the last step or the beginning

of a new iteration in the consolidation of the proposed strategy. The

maintenance of the openness of the IT solution depends on an

interoperability certification process able to validate the conformity of

the proposed products against the published specifications.


169

The ISoS-M methodology requires clear independence of the end-users (public

authorities, large organizations acquiring an IT solution) and research institutions

from the competing IT technology suppliers, which we propose to constitute partners

during the development process. The ISoS establishes a mindset to move from

software to systems thinking (systems as black boxes). The move suggests a mapping

of business requirements for the system’s capabilities. The software thinking moves

to systems thinking based on the Isystem or CES as “black-boxes” concepts and

robust modularity elements to accommodate the diversity of programmatic and

execution cultures (isolation of implementation issues). Under the methodology to

develop complex ISoS, the project should adopt this objective and guide the

validation strategy towards a maximum separation between ITsystems thinking (the

composites) and software component development methodologies and practices.

6.4 Open Innovation and Value Creation

Open innovation is a research topic that has deserved crescent attention during the

last decades. However, researchers from management areas have, in some cases,

contributed to an apparent oversimplification of the underlying complexity. The

permission-less concept seems to be the key to the required openness for the

opportunity for innovators to add value [35]. The lack of a genuinely open

modularity framework to cover the total integration requires a complementary

approach to moderate such innovation potential by forcing the market to adhere to

open consensus. For the ISoS to achieve a real application, it needs to be pushed by

a high-value expectation, e.g., a scale informatics technology landscape to be

tendered, to induce the adoption by potential suppliers of any size on adopting the

ISoS open specifications.

Construction of critical complex Isystem of systems as IT-service of services

(ISoS) requires a consensus induced by some force, which is not easy to achieve in

the free innovation processes. The development of agnostic ISoS does not have a

simple formulation, as discussed in [149]. The proposed concepts, from CES, CEDE,

and at the collaborative networked organization's middleware level - the ECoNet,

needs further research to enable its adoption as universal open approaches.

Our results demonstrate the potential value of adopting the ISoS-M

methodology as a strategy to develop acquisitions for a new generation of open

technology landscapes in large organizations. Public organizations can play as

reference examples, thus reducing acquisition costs and obtaining the return of

investment in research. Our work has also shown the need to create a trusted

ecosystem to facilitate the involvement of startup in productizing results and


170

consequently being subcontracted by large end-user companies. As discussed in

[149], the proposed approach enables a decision for valuable bids by adopting from

cost advantage proposals, even when the bidders are not well-branded companies.

An essential requirement to trust any potential bidder is certification conformity of

products or services and product lifecycle development, as well as the

maintenance/support competencies.

6.5 Summary

The technology dependencies enforced by a unique supplier for the lifecycle

management of informatics systems or complex Isystem of systems drives our

research work. The existing standards are not complete or targeted to unify the

technologies or competencies that might lead to the development of open and

integrated systems.

While the diversity of research threads in complementary areas is essential to

advance in answering specific requirements, new integration challenges have

emerged, generating a trend for the need for total integration. The cyber-physical

systems community that question the roles of systems engineering and software

engineering is an example domain with the need to well understand each of the

components that make a part of the whole, in a well-coordinated manner, i.e.,

understanding the parts that are potentially developed by different processes and


The presented cases demonstrate the need for a kind of “science diplomacy”,

what is in line with recently pushed by the American Association for the

Advancement of Science (AAAS), to formalize the development of trust among

nations through scientific collaborations [58]. The fierce competition among

companies to maintain their market share and obtain an edge from their position to

lead integration dynamics requires such an approach where science can play a

significant role by founding conventional methods towards broad consensus. The

adoption and the contribution of open specifications and open source dynamics are

the way to obtain open value frameworks for different complementary facets of the

upcoming total integrated Isystems. As concluded in [116]: “As nations increasingly

trade and enhance commercial connections overseas, establishing a top-down

approach of diplomacy for science can yield greater returns for bottom-up

innovation, or science for diplomacy,” the globalization is pushing for new ways to

create value. For the discussion towards strengthening diplomacy with science, the

main objective is to bring a scientifically well-founded approach to increase trust in

the value created by countries and their developers, irrespectively of their importance

6.5 Summary

171

and relevance. The thesis also aims to be grounded in this view of the development

of science, founded on the approach to the open system of systems. A company of

any size, from start-up to an established company, shall be able to compete for

different computational responsibilities.

173

Chapter 7

7 Conclusions and Further

Research Challenges

Our research demonstrated value creation in the emerging system of systems,

through cost reduction at artifacts (components) level, and achieving Isystems /

CESs modularity, when multiple suppliers can provide compatible technology

products. We exemplify cost reduction for specific computational responsibilities,

e.g., those found in the Road Side Equipment (RSE) cyber-physical system, in the

tolling of the Electronic Toll Collection (ETC) case, and in the cinemometer and

cabinet for the speed enforcement system (SINCRO) case. These cases contributed

to validating our proposed ISoS framework, and constitute the first step towards its

adoption by the industry. This chapter summarizes our achieved results and points

out the remaining weaknesses and potential for further research. Some additional

research is necessary for fine-tuning and the effective adoption of our modularity

framework for integrated Informatics Systems Engineering to answer the fast-

growing open (multi-supplier and vendor-agnostic) “total integration” requirement

that is emerging in the market.

7.1 Summing up

Our proposed approach strongly contributes to the initial research question addressed

in the thesis. On revisiting the main research question:

“How to establish a multi-vendor informatics technology landscape

to support addressing the emergent innovative integrated services, when

involving a network of stakeholders, e.g. providing the single window,

while considering the current chaos organizations are facing to manage

their assortment of (legacy) Isystems - in most cases as “automation

Chapter 7 Conclusions and Further Research Challenges

174

islands” - where new and legacy systems have been integrated through ad

hoc strategies, leading to strong technology dependencies and vendor

lock-in?”

We define and develop an adaptive modularity computing framework as a

convergence strategy for the required open informatics system of systems landscape.

Our approach demonstrates, through its foundation cases and the scientific

community reviews, that the proposed strategy results in measurable costs reduction

when and if the acquisitions follow an effective market competition in provision of

substitutable components. Nevertheless, as we further address in this chapter, further

research and standardization efforts are necessary for effective adoption by industry

of the formulated informatics systems (ISoS framework). Furthermore, the

leadership of such standardization efforts needs to move from the potential big

supplier companies to neutral software developing/using consortia. Such neutral

consortia must work under user-organizations leadership investing in efforts towards

promoting standard substitutable technology artifacts. One identified obstacle to the

substitutability principle relates to the constraints presented by managing the

antagonistic interest of market players. Industry suppliers of a technology artifact

commonly introduce innovative features or use specific technologies to differentiate

products and remain competitive. These differentiations establish specific

technology implementations of systems or elements of systems, rendering their

integration difficult. Open source dynamics currently adopt a strategy to achieve

network effect [173], thus increasing the value from a generalized adoption by the

market through a free community edition. However, in many cases, the open-source

model restricts the community edition, which is typically limited, when compared to

the product version (enterprise edition), that offers a sufficient set of capabilities,

ready to be deployed.

In all cases, if establishing partial imposition of standard specifications for

specific computational and cyber-physical (and electrical and mechanical)

responsibilities, demonstrate reduction of costs. Following an open approach fits

better the real world which is complicated, not only for dealing with unpredictable

variables, identified only at product development and integration stage, but also

because components are adopted at different levels of operation, by persons with

diverse backgrounds and expertise. Moreover, as expressed in the proposed Model-

Driven Open Systems (MDEOS) program (see the discussion in Section 5.4), our

research is centered on the informatics systems perspective and technology, rather

than on the processes perspective and functional area. As we have empirically

7.2 Contributions to Sustainable Integrated Isystems Landscapes

175

confirmed, a novel restructuring of the technology landscape is paramount to

converge towards a genuinely open informatics systems landscape.

The following subchapters formulate a discussion of the strengths and

weaknesses of our proposed framework. Further efforts for achieving greater

completeness are also presented and discussed evolving our proposed models under

concurrent, and multidisciplinary research threads.


A main contribution of our research is related to the service paradigm, initially

developed under the ITSIBus model [147] adopted for an Electronic Toll Collection

(ETC) system for the road transport sector, and applied to the industry Brisa case,

addressed in Sections 1.1.1, and in Chapter 3, especially in Section 3.1. The

evolution of the Cooperation Enabled System (CES), Section 4.1, is a refinement of

the ITSIBus model by proposing an adaptive mechanism for peer CES to obtain the

necessary information for implemented services, potentially based on different

technologies. The capability of ISoS to deal with different implementations

establishes the adaptive coupling mechanism, enabling computational artifacts

producers to prepare their products to operate in different technology environments.

Our approach formalizes the inherent motivation of the service paradigm as a loose-

coupling strategy to compose parts of a complex system. In our thesis, beyond

restricting interactions to well-defined interfaces, the I0 mechanism facilitates the

adaptation of components implementing services (under standardized APIs)

following the specific technology culture of the technology provider. The adopted

strategy can be regarded as one step towards enabling direct interactions between

components (CES) and Isystems without the need for intermediate adapters,

following the classic Enterprise Service Bus model.

One important design aspect of the proposed ISoS framework, as addressed in

Chapter 4, and especially Section 4.2.2.2, is the simplicity of the approach to

address the identified complexity in establishing an integrated view of the

organization’s computing technology landscape. To a large extent, ISoS is motivated

by the need for an adaptive coupling between peers, as heterogeneous computational

responsibilities, aiming to reduce the complex web of configuration procedures and

adapters commonly adopted by current approaches. The strategy is founded on the

experiences to develop homogeneous holistic approaches like that followed in the

nineties by OMG with the Object Management Architecture (OMA/CORBA) [190].

The need to accommodate diversity of legacy and novel technologies motivated us


176

to develop the interface of a CES component (systems' element) potentially

implemented based on different technology paradigms for the same interface I,

meaning that it can have equivalent implementations Ii, and Ij, based on different

technologies. In fact, as discussed in the next subchapter, this adaptability feature

establishes the proposed Open Adaptive Coupling Infrastructure (OACI) (Section

4.2.2.3) as an alternative to the classical Enterprise Service Bus (ESB) with the

advantage that it does not need an intermediate system for transformations, in order

to be realized by specific adaptations and eventually orchestrated. Therefore, our

approach facilitates the establishment of standard computational responsibilities

(CES) potentially implemented by different technology frameworks. This proposed

adaptive modularity is a contribution to consolidate supplier independence while

simultaneously helping to reduce operational risks by enabling unified and integrated

management of the technology landscape.

The simplicity of our proposed model for the enterprise integrated informatics

systems relies on the I0 (selfAwareness method) and the awareness-information

concept at the enterprise level. It means that any enterprise informatics systems

landscape, including its cyber-physical systems, is structured as Isystems, where the

Isystem0 plays a unique role, as a meta-Isystem. The Isystem0 makes possible unified

governance of the technology landscape. Other Isystems can access Isystem0 to look

for enterprise functionalities structured as Isystems. The centrally coordinated ISoS

through the exclusive and mandatory Isystem0 can smoothly replace the current

“chaos” made of “islands” of deployed heterogeneous computational

responsibilities. As discussed throughout this thesis, the proposed framework is

expected to establish convergence for a sustainable, more competitive, and an

organization’s informatics systems landscape integrated from inception.

7.2.1 Intra-organization and collaborative networks dimension

One foremost achievement of the thesis is the conciliation between the intra-

organization and inter-organization (CN) data exchanges through the ECoNet

collaborative networks infrastructure, platform, and ISoS CN framework, as

addressed in Chapter 5. A specialized Isystem, the Enterprise Collaboration

Manager (ECoM), is proposed as a single point for the organization’s Isystems to

join collaborative networks. The ECoM plays a formalization role for the assortment

of adapters, which organizations have to configure and deploy to interact with

business partners or public administration services. The main goal is to streamline

the framing of specific adapters the organizations have to incorporate to sustain their

business relations. Furthermore, as discussed, the ECoM can embed the diversity of

adapters under a common integration framework based on the Collaboration


177

Contexts (CoC) concept (Section 5.2). The proposed models do not break with the

AS-IS but rather suggest a convergence for an open framework where multiple

suppliers are expected to supply both ECoM Isystems and the CoC concept. The

design and development of the ISoS CN is our contribution in response to the RO.4,

which establishes an open collaborative infrastructure, as addressed in Chapter 5.

From the experienced cases, one main issue concerning an effective adoption

of research results is the lack of a national system innovation able to take risks on

validating innovative approaches. While not confirmed as a product, as discussed in

Chapter 6, the theoretical models introducing the multi-supplier concerns proved to

generate significant value and justified the investment in research for an extended

period (more than fourteen years in the case of the partnership between Brisa and

ISEL). Successful, proprietary, and incompatible products and services establishing

the organization’s technology landscapes, clearly require multidisciplinary research

efforts towards an answer to the fast-growing total integration requirements. Such

integration needs to be based on a strategy adapting a diversity of technology

paradigms and at the same time being agnostic at procurement and acquisition

decisions. Our initial approach to the design of ITSIBus model (called ISoS.0) is an

important contribution to the development of the ISoS framework, in response to the

RO.1, which supports integration through services, as discussed in Chapter 3. The

design and development of the ISoS framework is our contribution in response to

the RO.2, which establishes an open adaptive modularity framework, as discussed

in Chapter 4. We have however presented that in order to properly support the

requirements set by both the intra-organization as well as the inter-organization

collaborative network domains, establishing only an adaptive technology framework

is not sufficient. We have therefore provided the CEDE platform (discussed in

Chapter 5), as the strategy to respond to RO.3, which establishes the development

and deployment strategy for adopting ISoS, so that the Isystems and CES can be

maintained and evolved by different competing suppliers.

The open modularity agreed within the market in the case of the SINCRO case

(Portuguese national vehicle speed-enforcement network) is paramount. To

consolidate this approach, the CES, Isystem, and Isystem of systems abstractions

establish the formal ISoS enterprise model for an open informatics systems

landscape. The ISoS framework facilitates an Isystem product to lookup for services

provided by other deployed Isystems, potentially from a different supplier. Thus, the

ISoS establish an open and multi-vendor framework for the organization’s

technology systems. Therefore, the ISoS strongly contributes to state of the art.

Bellow we address four of its main strengths and four of its currently considered

future enhancements that opens the ground for further research:


178

• Strengths

o The ISoS specification is open and provides similar

opportunities for micro, small and medium technology, and

service companies in competing with large (well-established)

brands. Its development is led by the scientific community,

supported by public and private research funds, and with the

participation of private companies from start-ups to public or

private organizations;

o The substitution principle for Isystems and CES, is founded on

the development and maintenance of reference models and

reference implementations with the associated conformity

certification program, and has proved to be a strategy for

converging organizations towards sustainable informatics

technology landscapes;

o The ISoS framework accommodates a diversity of technology

cultures, and reducing to a minimum those aspects that are

under mandatory standardization. The product (an Isystem or a

CES) holds a unique mandatory entry point, the I0 interface

(awareness service), from which a peer introspects to access the

available services and its specific technology bindings;

o The ISoS streamline the extension of an organization’s

informatics systems to interact with business partners, joining

collaborative networks. The open ECoM/ECoNet framework

makes the convergence of interaction mechanisms, data

formats, and protocols under a unified message exchange and

collaboration supporting mechanisms.

• Potential for Enhancements

o The ISoS framework does not directly address the business

processes automation and technology bindings;

▪ As discussed in the research, there is a trend to model

the business processes based on standard processes

modeling language, e.g., BPMN and DMN with

technology bindings made of Isystem services access,

as discussed in further research subchapter;

o The ISoS framework does not directly introduce or cope with

Fault tolerance mechanisms, namely providing transparency

towards high availability of service implementation;

o The ISoS framework does not manage predefined Elasticity

mechanisms aiming at guaranteeing the quality of services


179

(QoS) at the Isystem or CES level. For instance, if there are

analytic Isystems with services requiring some Mexec maximum

execution time to answer a goal and which are not expected to

answer on time in a situation of execution platform overload,

some load balancing mechanism can be (implicitly) activated;

o The ISoS framework does not directly address Authentication

and authorization. It can be defined as the responsibility of a

traversal (common) specific Isystem, to manage authentication

and authorization in coordination to the other Isystems.

It is important to notice that the ISoS framework follows an imposition strategy

for structuring the organization's computing technology architecture, and by

adopting the Informatics Systems (Isystem) and CES as the core modeling element.

Other approaches rely on guidelines to define systems architectures not imposing

pre-defined structures or template basis. An example of such approaches is the

standard ISO/IEC/IEEE 42010 - “Systems and software engineering-architecture

description” [84], which gives an added importance to the systems perspective in

complementing software engineering approaches. In its introduction, the new

standard emphasizes the complexity of new informatics systems and promotes the

standardization by establishing a set of guidelines to be adopted in the definition of

system’s architectures. However, languages like SysML, OPM, and others have

demonstrated to be not enough to establish a common interoperable or even dynamic

adaptable technology landscape of elements and to establish substitutability by

design. Our approach challenges the substitutability paradigm as the key

contribution to sustainable integrated informatics systems landscapes. Sustainable in

the sense that procurement of new technology systems or elements is fully supported

and its support and maintenance costs are not dependent on unique suppliers, and

therefore market competition curbs the costs. Moreover, the proposed ISoS naturally

extends the intra-organization approach to the collaborative network's organizations

making the association of internal Isystems to interact with the business partner’s

Isystems through ECoNet/ECoM straightforward.

Another important remark is the freedom which the proposed ISoS framework

attributes to technology innovation, by not constraining CES or the Isystem’s

internal structure to the condition that the element makes the I0 interface available

under the standardized programming interface. An organization can manage its

competitiveness by adopting innovative and unique informatics systems without

compromising its integration strategy.

180

7.3 Future Research Work

Despite the potential of our achieved results, and the robustness of the proposed

models, for its effective adoption by the organizations (industry), it requires further

research. Informatics systems lean towards complex heterogeneous composites of

technology artifacts challenging to design, develop, and operate. Abstractions

grasping partial views of the problem domain are, in most cases, guided by specific

semantics influenced by the background of the involved designers and developers.

It is not easy to establish a clear border between Informatics Engineering as

responsible for structuring the technology landscape, and the application or

processes domains, as it is already recognized as a challenging gap [123], [17]. The

ISO/IEC/IEEE 42010 standard, as a recommended practice for Architectural

Description of Software-intensive Systems, recognizes the move towards a systemic

perspective, Systems, and Software Engineering - Architecture Description.

However, the required holistic approach to structure informatics systems integration

is not a simple endeavor, at least if an important precondition is to guarantee the

substitutability of elements in such a complex composite.

As a final remark, an important and challenging research driver is the fast-

growing agile collaborative networks (CN) where stakeholders (organizations) with

competing interests join and leave collaborative spaces supported by heterogeneous

Informatics and cyber-physical systems. Beyond a technology strategy, such

application domains require robust and concise models able to manage trust in an

open and risky environment, and supporting critical business services.

7.3.1 Addressing the gap between technology and

processes/application domains

The business processes automation and in particular the adoption of declarative

approaches based on business process definition languages, e.g., the Business

Process Model and Notation (BPMN), complemented by the Decision Model and

Notation (DMN) standards, have shown to be difficult for adoption as a generalized

model-driven development approach. While theoretically being a potential approach

to formalize functional requirements, mappings the defined processes to execution

elements has proven complex and faulty [123]. The bindings of activities to

execution technology elements (services) have required adopting specific

approaches, rendering this paradigm challenging to configure and manage.

Furthermore, in spite of contributions from the Business Process Execution

Language (BPEL), the lack of a standard execution binding strategy has contributed

to a diversity of market incompatible approaches. Such a variety of technology


181

artifacts is making technology systems or elements challenging to substitute and

maintaining the designed/developed models, e.g. processes, data, and business rules

challenging.

Another recurrent problem is to conciliate the document management

considering a diversity of formats, commonly across the organization, with the

assortment of informatics systems. Despite the success of emerging open source

initiatives, e.g., the Alfresco27 document management platform, the integration

challenge lacks a formal model able to make such a cross-sectional process-oriented

perspective easier to design, develop, maintain, and replace.

In order to benefit from applying ISoS to this business integration dimension, it

requires some further research to design a case and validate its potential. Our

proposed modularity makes it possible to group into autonomous responsibilities

some of the above discussed needs. As an example, an Isystem can be designed and

developed with the responsibility to enact process definitions, e.g., as defined in

BPMN with embedded DMN rules. However, the way services invocation

(synchronous and asynchronous) is operated, in other words how process instances

execute under complex coordination mechanisms, such as scalability, security, or

fault-tolerance needs to be defined. Therefore, this theoretically founded approach

needs to be further worked out to guarantee reliability for the execution of long-lived

processes (e.g. for hours, days, months, years), where process instances need to be

maintained consistently. One interesting question is to find the right founded strategy

to conciliate both Alfresco and the quite interesting Camunda28. Alfresco adopts the

Activiti29 business process design and management tool while Camunda has its

design and process development environment. One possibility is to consider that they

evolve as open-source to comply with the ISoS framework, both being

implementations of substitutable Isystems. There is however a major challenge for

the substitution possibility. The process instances (current state) and the respective

current and historical data need to transfer the control of the new Isystem. While

naturally isolated by Isystem borders, the substitution needs to be modeled after each

specific application domain is standardized through a reference architecture and

validated by a reference implementation. Furthermore, the conforming certification

process needs to be designed and implemented.

27 https://www.alfresco.com

28 https://camunda.org

29 https://www.activiti.org


182

7.3.2 Semantics standardization efforts

A key idea motivating the ISoS framework is offering a flexible approach for

modeling functional granularity; in other words, concerns for the size of each

computational responsibility, be it CES or Isystem. The fast-evolving “total

integration” paradigm establishes application domains demanding the best match

between domain requirements and the computing virtualization strategies.

Another important aspect is the need to rethink the separation between the

application domain and computing virtualization. This is assumed as a complex

match based on the diversity of computing-related technology strategies addressing

development and operations requirements. Current approaches have however been

an obstacle for the reduction of the risks associated with practiced integration

strategies that are adapter based and cause the vendor lock-in problem. By offering

an “isolation” intrinsic to CES and Isystems, the ISoS framework is positioned to

simplify the development of integrated technology solutions. If adopted as a strategic

framework, the market is free to adopt its own technology culture. The minimal

precondition is the computational responsibility complies with a reference

architecture, conditioned to the validation by a conforming certification process.

Semantic level standardization efforts shall include the construction of

computational responsibilities (CES or Isystems) as standard modularity for the

development of integrated new Isystem or from wrapping legacy systems. Such

multidisciplinary paramount efforts could be developed under the following research

threads:

• The role of authorities and public organizations in the development of

open frameworks is paramount by preceding their procurement (tender)

processes with some research on open multi-supplier acquisitions this

very well fits with the ISoS approach;

• Reutilization of computational responsibilities, e.g. an organization’s

persistence Isystem is necessary. Such a complex endeavor needs to be

associated with a cultural change where Isystem developers establish a

clear separation between internal and external modularity and the need

for modules to be adaptive to diverse scenarios. The proposed ISoS

framework proved to be a valuable contribution to such an approach;

• Integrated governance of the technology landscape can be the

responsibility of one specialized Isystem. It can be an example of a

semantics standardization of a complex responsibility in managing all

the cyber and informatics systems in a first tier. Open reference

architecture and implementation for such a holistic responsibility


183

require the modeling of complex collaborative chains involving the

technology suppliers of the ISoS technology landscape.

Such standardization also requires a strategic collaboration from specialized

expertise like data management and data analytics, distributed system, data security,

and systems intelligence, each one grouping several specialized perspectives. The

following Section discusses dependability, as a composite concept that groups

aspects from security to the reliability of the ISoS landscape.

7.3.3 Dependability of systems

With the rise of the trend for a higher level of integrations, one important aspect

concerns the reliability of the integrated system of systems. Failure identification in

multi-supplier technology landscapes, where different Isystems are of the

responsibility of different suppliers, needs to establish an operations and

maintenance model that guarantees efficient diagnostics and the planning of the

recovery procedures. Moreover, with the increase in computational capabilities, the

expectation is that an intelligent monitoring system facilitates preventing failures by

anticipating potential problems – prognosis also referred to as preventive

maintenance. The intelligent and integrated monitoring spanning Isystems or

elements from different suppliers introduce additional complexity. Such added

complexity motivated the development of a Genesis2 (G2) testbed generator

framework and a self-adaptation and behavior monitoring, research in the context of

the SCube [161] and COIN [52], European research projects. However, such

adaptive coordination of loosely coupled services needs a multi-layer strategy based

on a hierarchy of adaptations. For our proposed framework, the challenge is even

more complex, considering that a different supplier potentially nurtures each

system's element with specific characteristics. A coordination strategy needs to be

part of the proposed semantics standardization. An integrated intelligent monitoring

strategy requires CES to implement some Ii service offering status information the

operations of running instance.

Our ISoS framework enables modeling specific computational responsibilities

being available for the cooperation with other computational responsibilities, be

them at CES or Isystem levels. Nevertheless, the answer to critical processes under

a trusted holistic framework, satisfying the quality assumptions commonly

associated with dependability issues, makes us suggest a suite of complementary

research lines. However, before detailing them, it is essential to clarify the

dependability concept. Dependability defined as the “trustworthiness of computing

systems that allows reliance to be justifiably placed on the services it delivers”

relates to resilience [43]. Resilience is a key characteristic of dependability


184

strategies, requiring a formal structuration of complex composites (ISoS) based on

systems or elements from different suppliers. The structuration needs a service for

monitoring, diagnostic/prognostic, and complex dependencies analysis of the

assortment of heterogeneous elements, in such a way, user-organization can trust for

its critical business. Contributing to a system “thinking” the proposed ISoS

framework can influence this and other groups with a shift from software for a

systems approach, as discussed in Sections 2.2 and 4.2.1. The ISoS research suggests

promoting the two central research lines grouping some of the discussed concerns:

• Business process and services level management and monitoring –

This is a domain application management and monitoring, related to the

interpretation of requirements and the expected quality. It means that

potential specialized Isystems can be researched to manage and monitor

business processes execution. The Isystem services can be discovered

and semantically interpreted. The management and monitoring

interfaces can be identified and accessed by a common tool towards an

integration strategy for an organization. An added complexity is related

to processes that involve more than one organization or collaborative

process [158]. There is a need to explore the coordination of

collaborative processes based on the ECoNet platform considering

organization members exchange coordination information through the

ECoM Isystem;

• Cyber-Physical and informatics systems management and monitoring

– This technological dimension is closer to the DMTF standardization

initiatives. Monitoring is related to the proper operation of the ISoS

elements functioning. Monitoring ranges from sensor/cyber-physical

system (CES) to Isystem at different logical layers. The strategy can be

similar to that proposed for the business process/services. A specialized

Isystem (to be standardized through a reference architecture and

implementation) can take the computational responsibility of

monitoring all the other Isystems.

Another important aspect is the need for an open framework to manage the

liabilities and the risks associated with the involved technological suppliers. They

are stakeholders establishing a collaborative business to maintain and monitor the

ISoS technology infrastructure. It means that it is of the interest of an Isystem

supplier to guarantee that its product works appropriately and further offers advanced

diagnostic/prognosis support. However, the Isystems, as a consistent (integrated)

whole, the ISoS landscape, need to be coordinated. If the supplier of an Isystem

needs to make an intervention resulting from an event from its monitoring tool, this


185

intervention needs to coordinate with the management system of the ISoS landscape.

It configures a complex network of antagonist interests with identifiable risks (the

supplier responsible for the Isystem that manages the technology landscape has the

interest to substitute the mentioned advanced Isystem containing diagnostic

features). It sets up a need to research collaborative networks and strategies to

coordinate with the management of an organization’s ISoS technology landscape

under the best-balanced interests and to maximize the value for the user organization.

7.3.4 Security challenges and risks

The fast trend towards integrated computing infrastructures and domain applications

associated with the crescent number of experts capable of managing security leaks

brought the security issue to a first concern. The discussion is also pushed by what

has been commonly named the cyberspace to classify a current trend for everything

and every person connected through high-speed communication links. The current

Internet is, in fact, fast worldwide wireless or wired communication infrastructure,

also grounding an extensive interaction and information sharing infrastructure. Such

communication infrastructure is mainly based on the World Wide Web or only Web

(based on the HTTP protocol), a fast-growing infrastructure with origins from simple

concepts created by Berners-Lee from CERN. With such an open network, data and

services become potentially threatened by both eavesdropping or unauthorized

access from other security vulnerabilities challenging to research. In [95], a

foundational research on Systems Security Engineering (SSE) is addressed, which

classifies security issues comprehensively, into seven diverse areas, including

perspectives such as technology, stakeholders, and processes. These seven proposed

domains emphasize the need for establishing a holistic security design for systems,

to consist of: i) provision of organization’s security policies, addressing compliance

mechanisms, ii) preparing the involved human resources, iii) provision of systems

resilience, to support business continuity, iv) supporting operations in heterogeneous

environments, v) guaranteeing access to physical infrastructures and security

procedures, vi) supporting life cycle management of the heterogeneous technology

artifacts, and vii) provision of communication infrastructures to connect

heterogeneous systems.

These seven domain areas that the author in [95] also relates to several

complementary standardization initiatives (ISO-27002, FIP 200, CISSP29, etc.)

establishes the complexity of security aspects and their wide management

dimensions. The ISoS framework needs to consider and further research these

perspectives. While our research addresses some aspects of the above list of security

issues, among these seven open security research questions, ISoS significantly


186

contributes to the last open area. Currently, each informatics system independently

handles its authentication and authorization mechanism. This creates complex

problems for developing integrated systems, which require a common view of the

organization’s technology landscape. ISoS specifically addresses this challenge and

offers a solution.

Focusing on future research challenges, we are keen to bridge the current efforts

into our proposed ISoS framework. As we first step in our future research, we are

investigating the establishment of a dedicated computational responsibility to

coordinate all the security aspects. Such an Isystem could play the role of security

monitoring and at the same time with the responsibility to maintain auditing

information to help making a diagnosis in the presence of a security-related attack.

Furthermore, each Isystem might need to implement a specific Ii service interface as

a standard mechanism for the security cooperation towards a whole integrated

security responsibility strategy.

Evolving the organization’s technology landscapes towards advanced open

competing technology infrastructures is challenging since standardization is

commonly an antagonistic trend for innovative technology companies. The risks

associated with higher integration levels are not easy to manage to establish clear

responsibility borders and product responsibility domain. Furthermore, innovation

means adopting new technology approaches, and in most cases different from any

standard. Despite our ISoS technology diversity-aware framework, integrated

distributed systems are complex, requiring efforts from different perspectives,

including the technology development, reference models and reference

implementations, and leading technology strategies set by user organizations.

In summary, while needing further research efforts, the ISoS is a long-running

strategy for the development of open, integrated informatics systems landscapes. The

ISoS research can also be crossed with several other scientific and engineering

disciplines, since its proposed approach addresses different application domains, e.g.

cyber-physical systems, to control or manage computing elements that are structured

as Service parts and delivered as CES or Isystems.

The results obtained so far make us confident, being founded on both scientific

reviews and continuous investment by the granting stakeholders, that our proposed

computing structural modularity framework, its technology specificities, and

semantics-awareness are on the right path towards the development of fully

integrated and effective technology-agnostic landscapes.

187

Bibliography

[1] Condor-a hunter of idle workstations, 1988.

[2] Hamideh Afsarmanesh and Luis Camarinha-Matos. A Framework for

Management of Virtual Organization Breeding Environments. In Luis

Camarinha-Matos, Hamideh Afsarmanesh, and Angel Ortiz, editors,

Collaborative Networks and Their Breeding Environments, volume 186 of

IFIP International Federation for Information Processing, pages 35–48.

Springer Boston, 2005. 10.1007/0-387-29360-4_4.

[3] Hamideh Afsarmanesh and Luis M. Camarinha-Matos. Management of

Information Supporting Collaborative Networks. In DEXA ’09: Proceedings

of the 20th International Conference on Database and Expert Systems

Applications, pages 1–6, Berlin, Heidelberg, 2009. Springer-Verlag.

[4] Hamideh Afsarmanesh, Luis M. Camarinha-Matos, and Ekaterina Ermilova.

Vbe Reference Framework. In Luis M. Camarinha-Matos, Hamideh

Afsarmanesh, and Martin Ollus, editors, Methods and Tools for Collaborative

Networked Organizations, pages 35–68. Springer US, 2008. 10.1007/978-0-

387-79424-2_2.

[5] Aditya Agarwal, Mark Slee, and Marc Kwiatkowski. Thrift: Scalable Cross-

Language Services Implementation. Technical report, Facebook, 4 2007.

[6] Kyeongrim Ahn. The study of Single Window model for Maritime logistics.

In Advanced Information Management and Service (IMS), 2010 6th

International Conference on, pages 106–111, 2010.

[7] Youseef Alotaibi. Business process modelling challenges and solutions: a

literature review. Journal of Intelligent Manufacturing, 27(4):701–723, Aug

2016.

[8] L.M. Ascencio, R.G. GonzÃ¡lez-RamÃrez, L.A. Bearzotti, N.R. Smith, and

J.F. Camacho-Vallejo. A collaborative supply chain management system for

Bibliography

188

a maritime port logistics chain. Journal of Applied Research and Technology,

12(3):444 – 458, 2014.

[9] J. R. Aschenbrenner. Open Systems Interconnection. IBM Systems Journal,

25(3.4):369–379, 1986.

[10] Irina Astrova and Arne Koschel. Distributed osgi through apache cxf and web

services. In WEB 2013 The First International Conference on Building and

Exploring Web Based Environments, 2013.

[11] T.S. Baines, H.W. Lightfoot, O. Benedettini, and J.M. Kay. The servitization

of manufacturing: A review of literature and reflection on future challenges.

Journal of Manufacturing Technology Management, 20(5):547–567, 2009.

[12] A. Balalaie, A. Heydarnoori, and P. Jamshidi. Microservices Architecture

Enables DevOps: Migration to a Cloud-Native Architecture. IEEE Software,

33(3):42–52, May 2016.

[13] Carliss Y. Baldwin and Kim B. Clark. Modularity in the Design of Complex

Engineering Systems, pages 175–205. Springer Berlin Heidelberg, Berlin,

Heidelberg, 2006.

[14] Srividya K. Bansal. Towards a semantic extract-transform-load (etl)

framework for big data integration. In Proceedings of the 2014 IEEE

International Congress on Big Data, BIGDATACONGRESS ’14, pages 522–

529, Washington, DC, USA, 2014. IEEE Computer Society.

[15] Nils Barnickel, Johannes Böttcher, and Adrian Paschke. Incorporating

semantic bridges into information flow of cross-organizational business

process models. In Proceedings of the 6th International Conference on

Semantic Systems, I-SEMANTICS ’10, pages 17:1–17:9, New York, NY,

USA, 2010. ACM.

[16] OASIS-BusDox; BEDA. Business Document Exchange Architecture -

BEDA, March 2011.

[17] Wolfgang BÃ¶hm, Stefan Henkler, Frank Houdek, Andreas Vogelsang, and

Thorsten Weyer. Bridging the gap between systems and software engineering

by using the spes modeling framework as a general systems engineering

philosophy. Procedia Computer Science, 28:187 – 194, 2014.

[18] Athanassios Bouras, Panagiotis Gouvas, Dimitrios Kourtesis, and Gregoris

Mentzas. Semantic integration of business applications across collaborative

value networks. In Luis Camarinha-Matos, Hamideh Afsarmanesh, Paulo

Novais, and Cesar Analide, editors, Establishing The Foundation Of

Bibliography

189

Collaborative Networks, IFIP International Federation for Information

Processing, pages 539–546. Springer Boston, 2007. 10.1007/978-0-387-

73798-0_58.

[19] E. Brewer. Cap twelve years later: How the "rules" have changed. Computer,

45(2):23–29, Feb 2012.

[20] Eric A. Brewer. Towards Robust Distributed Systems (Abstract). In

Proceedings of the Nineteenth Annual ACM Symposium on Principles of

Distributed Computing, PODC ’00, pages 7–, New York, NY, USA, 2000.

ACM.

[21] R. Britto, D. Smite, and L. O. Damm. Software architects in large-scale

distributed projects: An ericsson case study. IEEE Software, 33(6):48–55,

Nov 2016.

[22] J. Browne, P. J. Sackett, and J. C. Wortmann. Future manufacturing systems–

towards the extended enterprise. Computers in Industry, 25(3):235 – 254,

1995. CIM in the Extended Enterprise.

[23] P. Bull, A. Grigg, L. Guan, and I. Phillips. A quality of service framework for

adaptive and dependable large scale system-of-systems. pages 1 –6, jun. 2010.

[24] Henning Butz. Open integrated modular avionic (ima): State of the art and

future development road map at airbus deutschland. department of avionic

systems at airbus deutschland gmbh. www.aviation-conferences.com, 2004.

[25] J. M. F. Calado, Luis A. Osorio, and Ricardo Prata. An Adaptive IoT

Management Infrastructure for EcoTransport Networks. In Risks and




[26] Joao M. F. Calado and A. Luis Osorio. Dynamic Integration of Mould

Industry Analytics and Design Forecastings, pages 649–657. Springer


[27] L. M. Camarinha-Matos, H. Afsarmanesh, C. Antunes, J. F. Clavier,

C. Garita, P. Gibon, A. Klen, H. Lenz, C. Lima, J. Mota, A. L. Osorio, A.rio,

R. Rabelo, H. Ribeiro, A. Schreiber, L. M. Spinosa, and Y. Ugur. The

PRODNET Demonstrator, pages 279–290. Springer US, Boston, MA, 1999.

[28] L. M. Camarinha-Matos, H. Afsarmanesh, E. Ermilova, F. Ferrada, A. Klen,

and T. Jarimo. ARCON reference models for collaborative networks. In

Luis M. Camarinha-Matos and Hamideh Afsarmanesh, editors, Collaborative

Bibliography

190

Networks: Reference Modeling, pages 83–112. Springer US, 2008.

10.1007/978-0-387-79426-6_8.

[29] Luis M. Camarinha-Matos. Collaborative networked organizations: Status

and trends in manufacturing. Annual Reviews in Control, 33(2):199 – 208,

2009.

[30] Luis M. Camarinha-Matos, Rosanna Fornasiero, and Hamideh Afsarmanesh.

Collaborative Networks as a Core Enabler of Industry 4.0, pages 3–17.


[31] John Carnell. Spring Microservices in Action. Manning Publications Co.,

Greenwich, CT, USA, 1st edition, 2017.

[32] G. Caronni. Walking the web of trust. In Enabling Technologies:

Infrastructure for Collaborative Enterprises, 2000. (WET ICE 2000).

Proeedings. IEEE 9th International Workshops on, pages 153–158, 2000.

[33] Tomas Cerny, Michael J. Donahoo, and Michal Trnka. Contextual

Understanding of Microservice Architecture: Current and Future Directions.

SIGAPP Appl. Comput. Rev., 17(4):29–45, January 2018.

[34] David Chappell. Enterprise Service Bus: Theory in Practice. O’Reilly Media,

July 2004.

[35] Henry Chesbrough and Marshall Van Alstyne. Permissionless innovation.

Commun. ACM, 58(8):24–26, July 2015.

[36] J. W. Coleman, A. K. Malmos, P. G. Larsen, J. Peleska, R. Hains,

Z. Andrews, R. Payne, S. Foster, A. Miyazawa, C. Bertolini, and A. Didierk.

Compass tool vision for a system of systems collaborative development

environment. In System of Systems Engineering (SoSE), 2012 7th

International Conference on, pages 451–456, July 2012.

[37] James A. Crowder, John N. Carbone, and Russell Demijohn.

Multidisciplinary Systems Engineering, pages 27–64. Springer International

Publishing, 2016.

[38] Morice Daudi, Jannicke Baalsrud Hauge, and Klaus-Dieter Thoben. A Trust

Framework for Agents’ Interactions in Collaborative Logistics, pages 53–63.


[39] Paul David. Path dependence, its critics, and the quest for ’historical

economics’. Working papers, Stanford University, Department of Economics,

2000.

Bibliography

191

[40] Shahir Daya, Nguyen Van Duy, Kameswara Eati, Carlos M Ferreira, Dejan

Glozic, Vasfi Gucer, Manav Gupta, Sunil Joshi, Valerie Lampkin, Marcelo

Martins, Shishir Narain, and Ramratan Vennam. Microservices from Theory

to Practice: Creating Applications in IBM Bluemix Using the Microservices

Approach. IBM Redbooks, 2015.

[41] A. Delgado, L. GonzÃ¡lez, and R. Ruggia. A Process-Aware Inter-

organizational Service Integration Platform to Support Collaborative

Organizations. In 2016 IEEE International Conference on Services

Computing (SCC), pages 844,847, June 2016.

[42] Deloitte. Multivendor network architectures, TCO, and operational risk.

Technical report, Deloitte Consulting LLP, February 2012.

[43] Grit Denker, Nikil Dutt, Sharad Mehrotra, Mark-Oliver Stehr, Carolyn

Talcott, and Nalini Venkatasubramanian. Resilient dependable cyber-physical

systems: a middleware perspective. Journal of Internet Services and

Applications, 3(1):41–49, 2012.

[44] Dov Dori. Object-Process Methodology: A Holistic Systems Paradigm.

Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2002.

[45] Bruce Powel Douglass. Agile Systems Engineering. Morgan Kaufmann

Publishers Inc., San Francisco, CA, USA, 2016.

[46] Dirk Draheim. Business Process Technology A Unified View on Business

Processes, Workflows and Enterprise Applications. Springer Berlin

Heidelberg, 2010.

[47] Jacques H . Dreze. William s. vickrey a biographical memoir. National

Academies Press Washington d.c., 1998.

[48] Marlon Dumas, Marcello La Rosa, Jan Mendling, and Hajo A. Reijers.

Essential Process Modeling, pages 75–115. Springer Berlin Heidelberg,

Berlin, Heidelberg, 2018.

[49] EC. Standardisation mandate forwarded to the european standardisation

bodies in the field of road transport telematics, April 1998.

[50] Owen Eriksson. Intelligent Transport Systems and Services (ITS), pages 425–

436. Springer US, Boston, MA, 2002.

[51] Craig Estridge, Timothy Eveleigh, and Berek Tanju. Integration of System

Modeling and Design Processes, Data and Technology for Streamlining

Bibliography

192

Enterprise Integration. Procedia Computer Science, 95:311 – 318, 2016.

Complex Adaptive Systems Los Angeles, {CA} November 2-4, 2016.

[52] F. M. Facca, S. Komazec, C. Guglielmina, and S. Gusmeroli. COIN: Platform

and Services for SaaS in Enterprise Interoperability and Enterprise

Collaboration. In 2009. ICSC ’09. IEEE International Conference on

Semantic Computing, pages 543 –550, sept. 2009.

[53] Dieter Fensel and Christoph Bussler. The web service modeling framework

wsmf. Electronic Commerce Research and Applications, 1(2):113 – 137,

2002.

[54] G. Feuerlicht. E-business interoperability: Challenges and opportunities. In e-

Business (ICE-B), 2011 Proceedings of the International Conference on,

pages 1–6, July 2011.

[55] Roy T. Fielding and Richard N. Taylor. Principled design of the modern web

architecture. In Proceedings of the 22Nd International Conference on

Software Engineering, ICSE ’00, pages 407–416, New York, NY, USA, 2000.

ACM.

[56] Roy Thomas Fielding. REST: Architectural Styles and the Design of Network-

based Software Architectures. Doctoral dissertation, University of California,

Irvine, 2000.

[57] consortium FIWARE. FIWARE GE Open Specifications. Technical report,

FIWARE consortium Project Document Number: ICT-2011-FI-285248-

WP6-D.6.1.1b, 2012.

[58] American Association for the Advancement of Science AAAS. New frontiers

in science diplomacy; navigating the changing balance of power. The Royal

Society Science Policy Centre

https://www.aaas.org/sites/default/files/New_Frontiers.pdf, January 2010.

[59] Ian Foster and Carl Kesselman. The history of the grid. 20(21):22, 2010.

[60] Ian Foster, Carl Kesselman, and Steven Tuecke. The anatomy of the grid:

Enabling scalable virtual organizations. Int. J. High Perform. Comput. Appl.,

15(3):200–222, August 2001.

[61] Timothy J. Foxon. Technological and institutional ’lock-in’ as a barrier to

sustainable innovation. In Imperial College Centre for Energy Policy and

Technology (ICCEPT), editors, ICCEPT Working Paper. ICCEPT, 2002.

Bibliography

193

[62] R. L. French. Historical overview of automobile navigation technology. In

36th IEEE Vehicular Technology Conference, volume 36, pages 350–358,

May 1986.

[63] Veronica Gacitua-Decar and Claus Pahl. Ontology-based Patterns for the

Integration of Business Processes and Enterprise Application Architectures.

IGI Global, 2010.

[64] Yu Gan and Christina Delimitrou. The Architectural Implications of

Microservices in the Cloud. CoRR, abs/1805.10351, 2018.

[65] Peter D. Gentile. Theory of Modularity, a Hypothesis. Procedia Computer

Science, 20(0):203 – 209, 2013. Complex Adaptive Systems.

[66] T. Gherbi, D. Meslati, and I. Borne. MDE between Promises and Challenges.

In Computer Modelling and Simulation, 2009. UKSIM ’09. 11th International

Conference on, pages 152–155, March 2009.

[67] George A. Giannopoulos. Towards a european its for freight transport and

logistics: results of current eu funded research and prospects for the future.

European Transport Research Review, 1(4):147–161, 2009.

[68] C. Giardino, M. Unterkalmsteiner, N. Paternoster, T. Gorschek, and

P. Abrahamsson. What Do We Know about Software Development in

Startups? IEEE Software, 31(5):28–32, Sept 2014.

[69] J. Sales Gomes, GastÃ£o Jacquet, Miguel Machado, A. Luis Osorio, Carlos

Goncalves, and Manuel Barata. An open integration bus for efc: The its-ibus.

In ASECAP conference. ASECAP-2003, 18 - 21 May 2003 in Portoroz,

Slovenia, May 2003.

[70] Jorge Sales Gomes. Brisa Innovation.

https://www.google.pt/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad

=rja&uact=8&ved=2ahUKEwiIsdSa2MLgAhUy1uAKHS_BBk8QFjACegQ

IBxAC&url=http%3A%2F%2Fwww.aicep.pt%2Fframework%2Fdownload.

php%3Fid%3D15&usg=AOvVaw0CSEUuzyPiEpE3rZXLxY8T, May 2011.

[71] Joaquin Guillen, Javier Miranda, Juan Manuel Murillo, and Carlos Canal.

Developing Migratable Multicloud Applications Based on MDE and

Adaptation Techniques. In Proceedings of the Second Nordic Symposium on

Cloud Computing & Internet Technologies, NordiCloud ’13, pages 30–

37, New York, NY, USA, 2013. ACM.

Bibliography

194

[72] Alejandro SÃ¡nchez Guinea, GrÃ©gory Nain, and Yves Le Traon. A

systematic review on the engineering of software for ubiquitous systems.

Journal of Systems and Software, 118:251 – 276, 2016.

[73] Anura Guruge. 1 - web services: What, why, and where? In Anura Guruge,

editor, Web Services, pages 1 – 53. Digital Press, Burlington, 2004.

[74] Booz Allen Hamilton. History of intelligent transportation systems.

WWW.ITS.DOT.GOV/INDEX.HTM U.S. Department of Transportation

Intelligent Transportation Systems Joint Program Office PUBLICATION

NUMBER: FHWA-JPO-16-329, May 2016.

[75] Mark Hansen, Stuart Madnick, and Michael Siegel. Data Integration Using

Web Services, pages 165–182. Springer Berlin Heidelberg, Berlin,

Heidelberg, 2003.

[76] Wilhelm Hasselbring. Information System Integration. Commun-ACM,

43(6):32–38, June 2000.

[77] Tally Hatzakis, Mark Lycett, Robert D. Macredie, and Valerie A. Martin.

Towards the development of a social capital approach to evaluating change

management interventions. Eur. J. Inf. Syst., 14(1):60–74, March 2005.

[78] J. Hedman, S. Henningsson, and B. Johansson. Towards a framework for

enterprise system integration in industries. In 1st Workshop on 3rd Generation

Enterprise Resource Planning Systems, 2008.

[79] Alan Hevner and Samir Chatterjee. Design Science Research in Information

Systems, pages 9–22. Springer US, Boston, MA, 2010.

[80] Babak Heydari, Mohsen Mosleh, and Kia Dalili. From modular to distributed

open architectures: A unified decision framework. CoRR, abs/1605.00682,

2016.

[81] Volker Hoyer-Fredrich, Till Janner, Christoph Schroth, Ivan Delchev, and

Florian Urmetzer. FAST platform: a concept for user-centric, enterprise class

mashup. 08 2018.

[82] James Huxtable and Dirk Schaefer. On servitization of the manufacturing

industry in the {UK}. Procedia {CIRP}, 52:46 – 51, 2016. The Sixth

International Conference on Changeable, Agile, Reconfigurable and Virtual

Production (CARV2016).

[83] IBTTA. Report on tolling in the united states. Technical report, 2015.

Bibliography

195

[84] ISO_IEC_IEEE_42010_. Systems and software engineering–architecture

description; survey of architecture frameworks, January 2017.

[85] Bertrand Ivar and Richard. The semat-software engineering method and

theory-vision satement. http://semat.org/documents/20181/27952/SEMAT-

vision.pdf/16059a36-a0ba-4405-b883-4a11a2131cea, 2009.

[86] S. Jacobs, N. Wengrowicz, and D. Dori. Defining Object-Process

Methodology in Web Ontology Language for Semantic Mediation. In 2014

IEEE International Conference on Software Science, Technology and

Engineering, pages 87–95, June 2014.

[87] Ivar Jacobson and Harold Bud Lawson, editors. Software Engineering in the

Systems Context. College Publications, 2015.

[88] Wil Janssen, Marc Lankhorst, Timber Haaker, and Henny de Vos. From

Service Innovation to Service Engineering, pages 33–51. Springer New York,

New York, NY, 2012.

[89] Vahid Javidroozi, Ardavan Amini, Adrian Cole, and Hanifa Shah. Business

Process Change in Enterprise Systems Integration - Challenges and

Opportunities. In Proceedings of the 16th International Conference on

Enterprise Information Systems - Volume 1: ICEIS,, pages 128–135, 2014.

[90] Nils Joachim, Daniel Beimborn, and Tim Weitzel. The influence of {SOA}

governance mechanisms on {IT} flexibility and service reuse. The Journal of

Strategic Information Systems, 22(1):86 – 101, 2013. Service Management

and Engineering in Information Systems Research.

[91] Nicolai Josuttis. Soa in Practice: The Art of Distributed System Design.

O’Reilly Media, Inc., 2007.

[92] Hee Won Kang, Jong Woo Kim, and Sung Joo Park. Integrated modeling

framework for manufacturing systems: A unified representation of the

physical process and information system. International Journal of Flexible

Manufacturing Systems, 10(3):231–265, 1998.

[93] Anish Karmarkar. SCA: A Model for Data and Service Integration on the

Web? Technical report, Oracle, URL address:

https://www.w3.org/2011/10/integration-

workshop/p/WDSI_AnishKarmarkar_PositionPaper.pdf, September 2011.

[94] C. B. Keating and A. V. Gheorghe. Systems thinking: Foundations for

enhancing system of systems engineering. In 2016 11th System of Systems

Engineering Conference (SoSE), pages 1–6, June 2016.

Bibliography

196

[95] S. Khou, L. O. Mailloux, and J. M. Pecarina. System-Agnostic Security

Domains for Understanding and Prioritizing Systems Security Engineering

Efforts. IEEE, Access, 5:3465–3474, 2017.

[96] Tom Killalea. The hidden dividends of microservices. Commun. ACM,

59(8):42–45, July 2016.

[97] Holger Knoche. Sustaining runtime performance while incrementally

modernizing transactional monolithic software towards microservices. In

Proceedings of the 7th ACM/SPEC on International Conference on

Performance Engineering, ICPE ’16, pages 121–124, New York, NY, USA,

2016. ACM.

[98] Marco Konersmann, Moritz Balz, and Michael Goedicke. Representing

formal component models in osgi. In Software Engineering, 2010.

[99] G. Koscielny and S. Sadou. Dynamic reuse of services in distributed systems.

In Technology of Object-Oriented Languages and Systems, 1999. Proceedings

of, pages 305 –318, July 1999.

[100] G.P. Kumari, B. Kandan, and A.K. Mishra. Experience sharing on soa based

heterogeneous systems integration. In Services - Part I, 2008. IEEE Congress

on, pages 107 –108, july 2008.

[101] Young-Woo Kwon, Eli Tilevich, and Taweesup Apiwattanapong. DR-OSGi:

Hardening Distributed Components with Network Volatility Resiliency, pages

373–392. Springer Berlin Heidelberg, Berlin, Heidelberg, 2009.

[102] Young-Woo Kwon, Eli Tilevich, and William R. Cook. An assessment of

middleware platforms for accessing remote services. In Proceedings of the

2010 IEEE International Conference on Services Computing, SCC ’10, pages

482–489, Washington, DC, USA, 2010. IEEE Computer Society.

[103] Young-Woo Kwon, Eli Tilevich, and William R. Cook. Which middleware

platform should you choose for your next remote service? Service Oriented

Computing and Applications, 5(2):61–70, 2011.

[104] Nassim Laga, Emmanuel Bertin, and Noel Crespi. A web based framework

for rapid integration of enterprise applications. In Proceedings of the 2009

International Conference on Pervasive Services, ICPS ’09, pages 189–198,

New York, NY, USA, 2009. ACM.

[105] Maria A. Lambrou, Ørnulf Jan Rødseth, Howard Foster, and Kay Fjørtoft.

Service-oriented computing and model-driven development as enablers of

Bibliography

197

port information systems: an integrated view. WMU Journal of Maritime

Affairs, 12(1):41–61, 2013.

[106] Harald Lampesberger. Technologies for Web and cloud service interaction: a

survey. Service Oriented Computing and Applications, 10(2):71–110, Jun

2016.

[107] Leslie Lamport. Paxos Made Simple, Fast, and Byzantine. In Procedings of

the 6th International Conference on Principles of Distributed Systems.

OPODIS 2002, Reims, France, December 11-13, 2002, pages 7–9, 2002.

[108] C. Landauer and K. L. Bellman. Wrappings for one-of-a-kind software

development. pages 3987 – 3995, jan. 2002.

[109] Arnaud Lanoix and Olga Kouchnarenko. Component substitution through

dynamic reconfigurations. In Proceedings 11th International Workshop on

Formal Engineering approaches to Software Components and Architectures,

FESCA 2014, Grenoble, France, 12th April 2014., pages 32–46, 2014.

[110] Peter Gorm Larsen, Nick Battle, Miguel Ferreira, John Fitzgerald, Kenneth

Lausdahl, and Marcel Verhoef. The overture initiative integrating tools for

vdm. SIGSOFT Softw. Eng. Notes, 35(1):1–6, January 2010.

[111] Harold W. Lawson. A Journey Through the Systems Landscape. College

Publications, 2010.

[112] C. A. Lee, N. Desai, and A. Brethorst. A keystone-based virtual organization

management system. In 2014 IEEE 6th International Conference on Cloud

Computing Technology and Science, pages 727–730, Dec 2014.

[113] Wilfried Lemahieu. Web service description, advertising and discovery: Wsdl

and beyond, 2001.

[114] Alessandra Levcovitz, Ricardo Terra, and Marco Tulio Valente. Towards a

technique for extracting microservices from monolithic enterprise systems.

CoRR, abs/1605.03175, 2016.

[115] James Lewis. Micro services - java the unix way. In Conference for Java

Masters, 19-21 March, Krakaw, Poland, 2012.

[116] Igor Linkov, Sankar Basu, Cathleen Fisher, Nancy Jackson, Adam C. Jones,

Maija M. Kuklja, and Benjamin D. Trump. Diplomacy for science: strategies

to promote international collaboration. Environment Systems and Decisions,

36(4):331–334, 2016.

Bibliography

198

[117] B. H. Liskov. A Design Methodology for Reliable Software Systems. In

Proceedings of the December 5-7, 1972, Fall Joint Computer Conference,

Part I, AFIPS ’72 (Fall, part I), pages 191–199, New York, NY, USA, 1972.

ACM.

[118] Alan Long. Port community systems. World Customs Journal, 2009.

[119] Jorge Lopes, Nuno Sequeira, Rui Ricardo, and Carlos Costa. Traffic Data

Exchange And Publication Through The Datex Protocol. In Easyway 2nd

Annual Forum, 2009.

[120] Osorio A. Luis, Adam Belloum, Afsarmanesh Hamideh, and Camarinha-

Matos. Agnostic Informatics System of Systems: The Open ISoS Services

Framework. Springer International Publishing, 2017.

[121] Hamideh Afsarmanesh Luis M. Camarinha-Matos. Cooperative Systems

Challenges in Virtual Enterprises. In Advances in Networked Enterprises:

Virtual Organizations, Balanced Automation and Systems Integration, 2000.

[122] Dan C. Marinescu. Cloud Computing: Theory and Practice. Computer

Science Division; Department of Electrical Engineering & Computer Science;

University of Central Florida, Orlando USA, 2012.

[123] Valerie A. Martin, Mark Lycett, and Robert Macredie. Exploring the Gap

between business and IT: an Information Culture Approach. In Proceeding in

Action in Language, Organisations and Information Systems. in ALOIS, 2003.

[124] K. Masek, P. Hnetynka, and T. Bures. Bridging the component-based and

service-oriented worlds. In Software Engineering and Advanced Applications,

2009. SEAA ’09. 35th Euromicro Conference on, pages 47 –54, 2009.

[125] Johannes Meinecke, Martin Gaedke, and Martin Nussbaumer. A web

engineering approach to model the architecture of inter-organizational

applications. In in Conference on Component-Oriented Enterprise

Applications (COEA, 2005.

[126] J. H. Mikkola. Modularity and interface management of product architectures.

In Management of Engineering and Technology, 2001. PICMET ’01. Portland

International Conference on, volume Supplement, pages 599–609 vol.2,

2001.

[127] Juliana Hsuan Mikkola. Modularity and interface management: The case of

schindler elevators. IVS/CBS Working Papers 2001-6, Department of

Industrial Economics and Strategy, Copenhagen Business School, 2001.

Bibliography

199

[128] Dietmar P. F. Moller. Introduction to Cyber-Physical Systems, pages 81–139.


[129] Adrian Mos and Mario Cortes-Cornax. Business Matter Experts do Matter: A

Model-Driven Approach for Domain Specific Process Design and

Monitoring, pages 210–226. Springer International Publishing, 2016.

[130] W. Mulder and G. R. Meijer. Distributed Information Services Supporting

Collaborative Network Management, pages 491–498. Springer US, Boston,

MA, 2006.

[131] A. Myburgh. Situational software engineering complex adaptive responses of

software development teams. In Computer Science and Information Systems

(FedCSIS), 2014 Federated Conference on, pages 841–850, Sept 2014.

[132] Hongchao Nie, Xudong Lu, and Huilong Duan. Supporting bpmn

choreography with system integration artefacts for enterprise process

collaboration. Enterprise Information Systems, 8(4):512–529, 2014.

[133] Adegboyega Ojo, Edward Curry, and Tomasz Janowski. Designing Next

Generation Smart City Initiatives - Harnessing Findings And Lessons From A

Study Of Ten Smart City Programs. In 22nd European Conference on

Information Systems (ECIS 2014), 2014.

[134] OMG-BMM. Business motivation model (bmm), May 2015.

[135] OMG-BPMN. Business process model and notation (bpmn), January 2011.

[136] OMG-DMN. Decision model and notation (dmn), June 2016.

[137] OMG-SBVR. Semantics of business vocabulary and business rules (sbvr),

May 2015.

[138] OMG-SEMAT. OMG_SEMAT-Essence-Kernel and Language for Software

Engineering Methods-v1.1. Web, December 2015.

[139] OMG-SysML. Omg systems modeling language (sysml), September 2015.

[140] J. Opara-Martins, R. Sahandi, and F. Tian. Critical review of vendor lock-in

and its impact on adoption of cloud computing. In Information Society (i-

Society), 2014 International Conference on, pages 92–97, Nov 2014.

[141] The OpenGroup. The IT4IT Reference Architecture, Version 2.0. Number

C115 in Open Group Standard. Van Haren, October 2015.

[142] Bart Orriens. Modeling The Business Collaboration Context, January 2006.

[143] OSGi-Alliance. Agility and modularity: Two sides of the same coin, 2014.

Bibliography

200

[144] A. Osorio, Hamideh Afsarmanesh, and Luis Camarinha-Matos. Open services

ecosystem supporting collaborative networks. In Balanced Automation

Systems for Future Manufacturing Networks, volume 322 of IFIP Advances

in Information and Communication Technology, pages 80–91. Springer

Boston, 2010. 10.1007/978-3-642-14341-0_10.

[145] A. Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh. Cooperation

Enabled Systems for Collaborative Networks. In Adaptation and Value

Creating Collaborative Networks, volume 362 of IFIP Advances in


Boston, 2011. 10.1007/978-3-642-23330-2_44.

[146] A. Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh. Enterprise

collaboration network for transport and logistics services. In Camarinha-

Matos and Hamideh Afsarmanesh, editors, Collaborative Systems for

Reindustrialization, IFIP Advances in Information and Communication

Technology. Springer Berlin, 2013.

[147] A. Osorio, Carlos Goncalves, Paulo Araujo, Manuel Barata, J. Gomes, Gastao

Jacquet, and Rui Dias. Open Multi-Technology Service Oriented Architecture

for ITS Business Models: The ITSIBus Etoll Services. In Collaborative

Networks and Their Breeding Environments, volume 186 of IFIP

International Federation for Information Processing, pages 439,446. Springer

Boston, 2005. 10.1007/0-387-29360-4_46.

[148] A. L. Osorio, M. Barata, C. Goncalves, P. Araujo, A. Abrantes, P. Jorge,

Gomes Sales, G. Jacquet, and A. Amador. Interoperability Among Its Systems

with Its-Ibus Framework. In Emerging Solutions for Future Manufacturing

Systems, volume 159 of IFIP International Federation for Information

Processing, page 241 250. Springer Boston, 2005. 10.1007/0-387-22829-

2_25.

[149] A. Luis Osorio. Towards Vendor-Agnostic IT-System of IT-Systems with the


[150] A. Luis Osorio, Arnaldo J. Abrantes, Jorge C. Goncalves, Paul Araujo,

J. Miguel Machado, J. Sales Gomes, and Gastao C. Jacquet. Flexible And

Plugged Peer Systems Integration To ITS-IBUS: The Case Of EFC and LPR

Systems. In Processes and Foundations for Virtual Organizations, pages

231,240, 2003.

[151] A. Luis Osorio, M. Martins Barata, Arnaldo J. Abrantes, J. Sales Gomes, and

Gastao C. Jacquet. Underlying Its Business Processes With Flexible And

Bibliography

201

Plugged Peer Systems: The Open ITS IBus Approach. In PRO-VE, pages

221,230, 2003.

[152] A. Luis Osorio, Luis Camarinha-Matos, Hamideh Afsarmanesh, and Adam

Belloum. On Reliable Collaborative Multimodal Services. Springer


[153] A. Luis Osorio, Luis Camarinha-Matos, Hamideh Afsarmanesh, and Adam

Belloum. Towards a Mobility Payment Service based on Collaborative Open

Systems. Springer International Publishing, 2019.

[154] A. Luis Osorio, Luis Camarinha-Matos, Tiago Dias, and Jose Tavares.

Adaptive Integration of IoT with Informatics Systems for Collaborative

Industry: the SITL-IoT Case. Springer International Publishing, 2019.

[155] A. Luis Osorio, Lara Moura, Rui Costa, and Paulo Borges. Towards

Intelligent Mobility: The Mobility Intelligent Cooperative Systems

(MOBICS) Platform. In Proceedings of 7th Transport Research Arena TRA

2018, April 16-19, 2018, Vienna, Austria, 2018.

[156] A. Luis Osorio and Rui Oliveira. Sistema nacional de controlo de velocidade

(sincro). In Seventh Portuguese Road Congress (7 Congresso Rodoviario

Portugues - Centro Rodoviario Portugues - CRP), 2013.

[157] Luis Osorio, Carlos Goncalves, C. Goncalves, A. Pereira, B. Antunes,

N. Barrocas, and Antonio Amador. ITSIBUS Jini and RFID Open Service-

Oriented Architecture for Toll Management. In JavaONE - S. Francisco;

Session BOF (Birds-of-a-Feather) -9041, 2005.

[158] Luis A. Osorio and Luis M. Camarinha-Matos. Distributed Process Execution

in Collaborative Networks. Robot. Comput.-Integr. Manuf., 24:647–655,

October 2008.

[159] Luis A. Osorio, Luis M. Camarinha-Matos, and Hamideh Afsarmanesh.

ECoNet Platform for Collaborative Logistics and Transport. In Risks and




[160] consortium PEPPOL. PEPPOL Transport Infrastructure Service Metadata

Publishing (SMP). Technical report, PEPPOL, Grant Agreement number:

224974, Title: Pan-European Public Procurement Online, 2012.

Bibliography

202

[161] Klaus Pohl. S-Cube - The European Network of Excellence in Software

Services and Systems. Technical report, NoE (Network of Excellence)

Software Services and Systems Network, European project, 2012.

[162] Andrea Prencipe, Andrew Davies, and M. Hobday. The Business of Systems

Integration. 01 2005.

[163] Art Pyster, Rick Adcock, Mark Ardis, Rob Cloutier, Devanandham Henry,

Linda Laird, Harold â€˜Budâ€™ Lawson, Michael Pennotti, Kevin Sullivan,

and Jon Wade. Exploring the relationship between systems engineering and

software engineering. Procedia Computer Science, 44:708 – 717, 2015.

[164] Iyad Rahwan, Ryszard Kowalczyk, and Yun Yang. Virtual Enterprise Design

- BDI Agents vs. Objects, pages 147–157. Springer Berlin Heidelberg, Berlin,

Heidelberg, 2001.

[165] Arun Rai, Viswanath Venkatesh, Hillol Bala, and Mark O. Lewis.

Transitioning to a modular enterprise architecture: Drivers, constraints, and

actions. MIS Quarterly Executive, 9(2), 2010.

[166] Geoffrey Raines. Leveraging federal it investment with service-oriented

architecture. CROSSTALK The Journal of Defense Software Engineering,

2009.

[167] R. G. Rendon. Using a modular open systems approach in defense

acquisitions: Implications for the contracting process. In System of Systems

Engineering, 2007. SoSE ’07. IEEE International Conference on, pages 1–6,

April 2007.

[168] Omid M. Rouhani. Next Generations of Road Pricing: Social Welfare

Enhancing. Sustainability, 8(3):265, 2016.

[169] Sharon Ryan and Rory V. OConnor. Acquiring and sharing tacit knowledge

in software development teams: An empirical study. Information and

Software Technology, 55(9):1614 – 1624, 2013.

[170] Nazanin Sabooniha, Danny Toohey, and Kevin Lee. An Evaluation of

Hospital Information Systems Integration Approaches. In Proceedings of the

International Conference on Advances in Computing, Communications and

Informatics, ICACCI ’12, pages 498–504, New York, NY, USA, 2012. ACM.

[171] Mehran Sahami, Steve Roach, Ernesto Cuadros-Vargas, Elizabeth K.

Hawthorne, Amruth Kumar, Richard LeBlanc, David Reed, and Remzi Seker.

Acm/ieee-cs computer science curricula 2013: Implementing the final report.

Bibliography

203

In Proceedings of the 45th ACM Technical Symposium on Computer Science

Education, SIGCSE ’14, pages 175–176, New York, NY, USA, 2014. ACM.

[172] S. Sarkar, S. Ramachandran, G. S. Kumar, M. K. Iyengar, K. Rangarajan, and

S. Sivagnanam. Modularization of a large-scale business application: A case

study. IEEE Software, 26(2):28–35, March 2009.

[173] Suzanne Scotchmer. Innovation and Incentives, chapter Networks and

Network Effects, pages 289–318. MIT Press, 2004.

[174] E. Seidewitz. What models mean. IEEE Software, 20(5):26–32, Sept 2003.

[175] Pavel Shapkin, Alexander Marenkov, Leonid Shumsky, Vladimir Roslovtsev,

and Viacheslav Wolfengagen. Towards the automated business process

building by means of type theory. In Proceedings of the 7th International

Conference on Subject-Oriented Business Process Management, S-BPM

ONE ’15, pages 7:1–7:8, New York, NY, USA, 2015. ACM.

[176] Robert Siebeck, Till Janner, Christoph Schroth, Volker Hoyer, Wolfgang

Wörndl, and Florian Urmetzer. Cloud-based enterprise mashup integration

services for b2b scenarios. In 2nd Workshop on Mashups, Enterprise Mashups

and Lightweight Composition on the Web (MEM 2009) in conjunction with

the 18th International World Wide Web Conference (WWW2009), page 9,

April 2009.

[177] Mario Silic and Andrea Back. Technological Risks of Open Source Software

Adoption in the Organizational Context Linux in Munich (LiMux) Case. 01

2015.

[178] Javier Soriano, David Lizcano, Miguel A Cañas, Marcos Reyes, and Juan J

Hierro. Fostering innovation in a mashup-oriented enterprise 2.0 collaboration

environment. UK, sai: sisn, 24(2007):62–68, 2007.

[179] Manuel E. Sosa and Craig M. Rowles. Network approach to define modularity

of components in complex products. ASME Journal of Mechanical Design,

pages 1118–1129, 2007.

[180] Vijay Srinivasan. An integration framework for product lifecycle

management. Computer-Aided Design, 43(5):464 – 478, 2011. Emerging

Industry Needs for Frameworks and Technologies for Exchanging and

Sharing Product Lifecycle Knowledge.

[181] Pat Stepherd. Oracle SCA: The Power of the Compisite. Technical report,

Oracle White paper, August 2009.

Bibliography

204

[182] Volker Stiehl. Process-Driven Applications with BPMN. Springer, 2014.

[183] A. Szep, R. Smeikal, M. Jandl, and K. M. Goeschka. Dependable distributed

systems. In Companion to the 19th Annual ACM SIGPLAN Conference on

Object-oriented Programming Systems, Languages, and Applications,

OOPSLA ’04, pages 176–177, New York, NY, USA, 2004. ACM.

[184] Giovanni Toffetti, Sandro Brunner, Martin Blöchlinger, Florian Dudouet, and

Andrew Edmonds. An architecture for self-managing microservices. In

Proceedings of the 1st International Workshop on Automated Incident

Management in Cloud, AIMC ’15, pages 19–24, New York, NY, USA, 2015.

ACM.

[185] Stefan Tongur and Mats Engwall. The business model dilemma of technology

shifts. Technovation, 34(9):525 – 535, 2014.

[186] Frank Truyen. The fast guide to model driven architecture the basics of model

driven architecture. Web, January 2006.

[187] Sandra Vandermerwe and Juan Rada. Servitization of business: Adding value

by adding services. European Management Journal, 6(4):314 – 324, 1988.

[188] Pal Varga, Fredrik Blomstedt, Luis Lino Ferreira, Jens Eliasson, Mats

Johansson, Jerker Delsing, and Iker MartÃnez de Soria. Making system of

systems interoperable â€“ the core components of the arrowhead framework.

Journal of Network and Computer Applications, pages –, 2016.

[189] Iohan Gonçalves Vargas, Thiago Gottardi, and Rosana Teresinha Vaccare

Braga. Approaches for Integration in System of Systems: A Systematic

Review. In Proceedings of the 4th International Workshop on Software

Engineering for Systems-of-Systems, SESoS ’16, pages 32–38, New York,

NY, USA, 2016. ACM.

[190] S. Vinoski. Corba: integrating diverse applications within distributed

heterogeneous environments. IEEE Communications Magazine, 35(2):46–55,

Feb 1997.

[191] J. Waldo. Alive and well: Jini technology today. IEEE Computer,

33(6):107,109, Jun 2000.

[192] Jim Waldo. The Jini Specifications. Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA, second edition, 2000.

Bibliography

205

[193] Jim Waldo. Virtual Organizations, Pervasive Computing, and an

Infrastructure for Networking at the Edge. Information Systems Frontiers,

4:9–18, 2002. 10.1023/A:1015322219248.

[194] Bernhard Wally, Alexandra Mazak, Bernhard Kratzwald, and Christian

Huemer. Model-driven retail information system based on REA business

ontology and retail-h. In 17th IEEE Conference on Business Informatics, CBI

2015, Lisbon, Portugal, July 13-16, 2015 - Volume 1, pages 116–124, 2015.

[195] Kaiyu Wan, Nhat Nguyen, and Vangalur Alagar. Dependable traffic control

strategies for urban and freeway networks. Mobile Networks and Applications,

21(1):98–126, 2016.

[196] Youying Wang, Qian Huang, Robert M. Davison, and Feng Yang. Effect of

transactive memory systems on team performance mediated by knowledge

transfer. International Journal of Information Management, 41:65 – 79, 2018.

[197] Roelf J. Wieringa. Design science methodology for information systems and

software engineering. Springer, 2014. 10.1007/978-3-662-43839-8.

[198] Jiangyun Xu and Weichang Du. Software brokers for quality of services in

service-oriented distributed systems. In Proceedings. Second Annual

Conference on Communication Networks and Services Research, 2004., pages

341–344, May 2004.

[199] Zhonghua Yang and Keith Duddy. Corba: A platform for distributed object

computing. SIGOPS Oper. Syst. Rev., 30(2):4–31, April 1996.

207

Publications List – A selection of publications

most related to the Dissertation

1. A. Luis Osorio, Luis M. Camarinha-Matos, Hamideh Afsarmanesh, and

Adam Belloum. Towards a Mobility Payment Service Based on Collaborative

Open Systems. IFIP AICT series - Volume 568 - Collaborative Networks and

Digital Transformation, 20th International PRO-VE Conference, Turin, Italy,

September 23-25, pages 379–392. Springer International Publishing, 2019.

• A. Luis Osorio, developed the mobility payment service strategy and

wrote all sections of this paper. The co-authors supervised and

proofread the written work.

2. A. Luis Osorio, Luis M. Camarinha-Matos, Tiago Dias, and José Tavares.

Adaptive Integration of IoT with Informatics Systems for Collaborative

Industry: The SITL-IoT Case. IFIP AICT series - Volume 568 - Collaborative

Networks and Digital Transformation, 20th International PRO-VE

Conference, Turin, Italy, September 23-25, pages 43–54. Springer


• A. Luis Osorio, developed the adaptive integration of IoT and wrote

all sections of this paper. José Tavares validated the company

strategy. The other co-authors proofread the written work.

3. A. Luis Osorio, Luis M. Camarinha-Matos, Hamideh Afsarmanesh, and Adam

Belloum. On Reliable Collaborative Mobility Services. IFIP AICT series -

Volume 534 - Collaborative Networks of Cognitive Systems, 19th

International PRO-VE Conference, Cardiff, UK, September 17-19, pages

297–311. Springer International Publishing, 2018.

• A. Luis Osorio, developed the collaborative mobility services models

and wrote all sections of this paper. The remaining co-authors

supervised and proofread the written work.

Publications List

208

4. A. Luis Osorio, Adam Belloum, Hamideh Afsarmanesh, and Luis M.

Camarinha-Matos. Agnostic Informatics System of Systems: The Open ISoS

Services Framework. IFIP AICT series - Volume 506 - Collaboration in a

Data-Rich World, 18th International PRO-VE Conference, Vicenza, Italy,

September 18-20, pages 407–420. Springer International Publishing, 2017.

• A. Luis Osorio, developed the open informatics system of systems

(ISoS) framework and wrote all sections of this paper. The co-authors


5. A. Luis Osorio. Towards Vendor-Agnostic IT-System of IT-Systems with the

CEDE Platform. IFIP AICT series - Volume 480 - Collaboration in a

Hyperconnected World, 17th International PRO-VE Conference, Porto,

Portugal, October 3-5, pages 494–505. Springer International Publishing,

2016.

6. Luis A. Osorio, Luis M. Camarinha-Matos, and Hamideh Afsarmanesh.

ECoNet Platform for Collaborative Logistics and Transport. IFIP AICT series

- Volume 463 - Risks and Resilience of Collaborative Networks, 16th

International PRO-VE Conference, Albi, France, October 5-7, pages 265–276.


• Luis A. Osorio, formalized, developed, and demonstrated the

ECoNet platform and wrote all sections of this paper. The co-authors


7. A. Luis Osorio and Rui Oliveira. Sistema Nacional de Controlo de

Velocidade (SINCRO). In Seventh Portuguese Road Congress, Centro

Rodoviario Portugues, CRP Lisboa, Portugal, April 12, 2013.

• A. Luis Osorio, formalized, coordinated the development, and

validated the SINCRO architecture, and wrote all sections of this

paper. The co-author proofread the written work.

8. A. Luis Osorio, Luis Camarinha-Matos, and Hamideh Afsarmanesh.

Enterprise Collaboration Network for Transport and Logistics Services. IFIP

AICT series - Volume 408 - Collaborative Systems for Reindustrialization,

14th International PRO-VE Conference, Dresden, Germany, September 30 -

October 2. Springer Berlin, 2013.

• A. Luis Osorio, formalized the ECoNet collaborative network

infrastructure and wrote all sections of this paper. The co-authors


Publications List

209

9. A. L. Osorio, H. Afsarmanesh, and L. M. Camarinha-Matos. A Service

Integration Platform for Collaborative Networks. In the Journal of Studies in

Informatics and Control, Vol. 20, issue 1, January 2011, pp. 19-30, 2011.

• A. L. Osorio, formalized and validated the services integration

platform and wrote all sections of the article. The co-authors


10. A. Luis Osorio and Luis M. Camarinha-Matos. Distributed Process Execution

in Collaborative Networks. In the Journal of Robotics and Computer-

Integrated Manufacturing, 24(5):647–655, 2008.

• A. Luis Osorio, developed the proposed framework for distributed

business processes and wrote all sections of the article. The co-author


11. J. G. Silva, G. C. Marques, P. M. Jorge, A. J. Abrantes, A. L. Osorio, J. S.

Gomes, and J. C. Braga. Evaluation of an LPR-Based Toll Enforcement

System on Portuguese Motorways. In 2006 International IEEE Intelligent

Transportation Systems Conference, Toronto, Canada, September 17- 20,

pages 719–724, 2006.

• A. Luis Osorio, formalized and developed the ALPR architecture. J.

G. Silva wrote the initial version of all sections. The remaining co-

authors proofread the written work.

12. A. Luis Osorio, Carlos Goncalves, C. Goncalves, A. Pereira, B. Antunes, N.

Barrocas, and Antonio Amador. ITSIBUS Jini and RFID Open Service-

Oriented Architecture for Toll Management. In JavaOne Conference, San

Francisco, California; Session BOF (Birds-of-a-Feather)-9041, July 2005.

• A. Luis Osorio, formalized the ITSIBus models and the adoption of

JINI and wrote all sections of this paper. The remaining co-authors

proofread the written document and presented it at JavaOne.

13. A. Luis Osorio, Carlos Goncalves, Paulo Araujo, Manuel Barata, J. Gomes,

Gastao Jacquet, and Rui Dias. Open Multi-Technology Service Oriented

Architecture for ITS Business Models: The ITSIBus Etoll Services. IFIP

AICT series - volume 186 - Collaborative Networks and Their Breeding

Environments, 6th International PRO-VE Conference, Valencia, Spain,

September 26-28, pages 439–446. Springer Boston, 2005.

• A. Luis Osorio, formalized and developed the ITSIbus services

infrastructure and wrote all sections of this paper. The co-authors


Publications List

210

14. J. Sales Gomes, Gastão Jacquet, Miguel Machado, A. Luis Osorio, Carlos

Goncalves, and Manuel Barata. AN OPEN INTEGRATION BUS FOR EFC:

THE ITS-IBUS. In ASECAP International Conference. ASECAP-2003, 18 -

21 May 2003 in Portoroz, Slovenia, ASECAP, 2003.

• A. Luis Osorio, formalized the ITSIbus model applied to the

development of an open Electronic Toll Fee (EFC) system

(productization), and wrote the initial version of the paper. J. Sales

Gomes validated the Brisa company strategy in practice, and

presented the ETC system. The remaining co-authors proofread the

written work.

15. Osório A. L., Barata M. M. – Reliable and Secure Communications

Infrastructure for Virtual Enterprises, In the Journal of Intelligent

Manufacturing, Volume 12, pages 171-183, Kluwer Academic Publishers,

2001.

• Osório A. L., developed the PRODNET Communication

Infrastructure and wrote all sections of the article. The co-author


16. Camarinha-Matos L.M, Afsarmanesh H. Osorio A. L, Flexibility and privacy

in Virtual Enterprise infrastructures. In the International Journal of Computer

Integrated Manufacturing, special issue on WEB-based manufacturing in

Virtual Enterprises, Volume 14(1), pages 66-82, May 2001.

• Osório A. L., wrote the safe communication section of the article. The

co-authors wrote the remaining chapters and supervised and proofread

the written work.

211

Code

Throughout the development of ISoS Framework, the repository of its complete

reference implementation, was hosted on the servers of the Polytechnic Institute of

Lisbon. However, in the last few months, due to changes in the IT support services

of this institute, the generated code for ISoS framework, had to be relocated to

another server. Since October 2020, temporarily all the ISoS code has been moved

to Github under MDEOS GitHub Education private organization30.

The following must however be noted:

• The ISoS reference implementation is developed in close partnership with

the FORDESI31 software company in Lisbon that is investing in adopting

and contributing to the open-source.

• The current GitHub repository of the software is private, until it gets fully

formalized under the Open Source Initiative. In order to access this Github

repository for academic purposes, please send a “request access” email to:

[email protected].

• The MDEOS repositories will be made public, in collaboration with

FORDESI1, as soon as they are fully complying with governance of the

open-source initiative.

• The ECoNet platform software developed in the MIELE project (as also

explained below), is now being migrated to the new MDEOS GitHub

repository.

Validation Cases Code

As presented in Chapter 6, different components of the code that we generated

through our research, have been successfully tested and validated by several software

30 github.com/mdeos/isos

31 https://www.fordesi.pt/en/

Code

212

companies and businesses. These companies adopted and integrated our code base

in systems built to fit specific cases. More details about these validation cases code

are provided below. Our approach and codebase have been incorporated in the daily

activities of the companies listed below:

• Brisa32 company has adopted the code developed for ETC case and is

applying it since 2005 in their service adapters for the roadside equipment

part of the electronic toll collection system. Note that the code specifically

developed for this validation test case is protected by IP rights of Brisa and

can therefore not be put in the public domain.

• BP Portugal33 has deployed our developed HORUS system in to build

validation test case. Their generated system is productized and maintained

since 2014 by a start-up software engineering company Exploitsys34.

Exploitsys company is founded by several senior developers at the GIATSI

research group of BP Portugal, which were also involved in the

development of HORUS. The code developed for HORUS is incorporated

in a software package which is supported by Exploitsys35, and therefore it

is IP protected and cannot be put in the public domain.

• ANSR36 National Road Safety Authority productize the SINCRO system

since 2014. The SINCRO system is supported under the responsibility of

ANSR’s IT department. It is therefore IP protected and cannot be put in the

public domain.

We have designed the ECoNet platform software together with the GIATSI research

group of BP Portugal, in the MIELE research & development project. This code has

not been maintained since the end of the MIELE project in 2015. At present, together

with FORDESI, we are reimplementing the ECoNet as open-source, which will be

migrated as a part of the new MDEOS GitHub repository.

32 https://www.a-to-be.com/

33 https://www.bp.com/pt_pt/portugal

34 http://www.exploitsys.com/

35 http://www.exploitsys.com/project/refueling-supervision-horus/

36 http://www.ansr.pt/

213

Acknowledgments

The writing of acknowledgments is perhaps the riskiest effort, so the reader

shall assume that the mentioned names are only a few of the many contributions

along with my long research way.

My deep gratitude goes to Prof. Hamideh Afsarmanesh that always believed in

me to develop a Ph.D. I’m indebted to her patience, enthusiasm, and wisdom

guidance, helping me be a better researcher. My deep gratitude also goes to Dr.

Adam Belloum that promptly accepted and enthusiastically supported and motivated

the research and the writing of the thesis.

I’m also indebted to Prof. Luís Camarinha-Matos that always pushed me to

develop Ph.D. research following a collaboration for many years in European and

national granted research projects.

Many thanks to my friends and colleagues at ISEL, with special gratitude for

the insistent pushing efforts from Manuel Barata, and the valuable contributions of

José Igreja and João Calado for formalizations and other assistance along with the

writing of the thesis.

The research would not be possible without the visionary wisdom of the

entrepreneurial and public organization managers that believe knowledge

development can create industry value through investing in science and technology

research, and therefore generating this way value for the society.

• The Brisa ETC case grounds on the vision and will of Prof. João Bento, the

outstanding management capabilities of Eng. Jorge Sales Gomes, the tacit

support of Brisa’s President Dr. Vasco Mello, and the fantastic engineering

team headed by Eng. António Amador. They were the key enablers and

pushers for the Brisa (ETC case) research. Also, a special acknowledgment

for the entrepreneur Eng. José Rui Soares from Whatever/BTEN applied

many research contributions and was a key partner for the value creation.

Not less important, the Makewise start-up, led by Eng. Gonçalo Abreu and

Eng. Pedro Manuel has also been a valuable partner in this and other cases.

Acknowledgments

214

Even if the administrations changed, the trust in the research continued. The

research partnership has been a continuous investment since 2002.

• The HORUS case started with Galp/Galpgeste from the vision of Eng.

Miguel Pereira, Eng. Joaquim Lima and continued with the joining of BP

Portugal because of the visionary will of Eng. Pedro Oliveira, Dr. Abel Pina,

and the team that has made HORUS an industry success case. A special

mention to the start-up Exploitsys headed by João Assunção and Tiago

Garcia, and the start-up Makewise.

• The SINCRO case owes to Eng. Paulo Marques Augusto, at the time (2010)

President of National Road Security Authority (ANSR). The success was

also the vision and willingness of the technical director Eng. Rui Silva

Oliveira and the commitment of the research and of the development team

who among others, had the participation of João Assunção, Paula Graça,

Tiago Garcia, and Duarte Carona.

• The MIELE case was possible by the European research grant support and

the decision of APL and APDL, respectively Administrations of the ports of

Lisbon and Leixões/Porto, wisely managed by Dra. Clara Xavier and Eng.

Luís Marinho Dias. The research fellows Paula Graça, Tiago Dias, Inês

Guilherme, Ana Mourato, were also of paramount importance.

Also critical is the project management led by João Paulo Sá, since HORUS

Galt/Galpgeste phase, as an essential contribution to the always complex

expectations and relationship management between science and technology research

and industry community.

The strategy to address the lifecycle management of open informatics systems

in the digital total integration era is also due to Ricardo Rabelo, Luís Asusnção,

Carlos Gonçalves, Tiago Dias, and many others. The warmed discussion usually

leads to reinforcing introspections and, for sure, helped to consolidate the continuous

search for the challenging research questions.

Returning to the first half of the Brisa case, the partnership between the

ISEL/GIATSI research group and the groups ISEL/M2A headed by Arnaldo

Abrantes and Pedro Mendes Jorge in the area of automatic learning and vision and

ISEL/GIEST led by António Serrador in the area of electronics and

telecommunications were vital for the Brisa/ETC case. A special mention for Eng.

Ricardo Prata, at the time fellow of GIEST group and later entrepreneur heading

Dailywork, for his contributions to the Brisa/ETC case.

I’m sure there are many other names I’m in debt for valuable experiences and

knowledge exchange. Empirical pieces of evidence demonstrate that it is possible to

Acknowledgments

215

create value by better managing synergies between science and technology and

industry and, therefore, contributing to the wellbeing of European and the global

society. However, there is the need for decision-makers to believe they will win if

they ground decisions on competing procurements, based on open standards imposed

through science and technology research moderation.

Perhaps most critical, my family's support, with special thanks to my wife Paula

for her unconditional encouragement and continued pressure. And the expectations

of my always attentive three adult children, Maria, Luísa, and João, about the end of

the father's long-standing effort.

My sincere thanks to all.

217

Abstract

A growing number of emerging applications, such as those involving cyber-

physical systems, require interaction/integration and subsystems infusion among

their components, which in turn require developing an integrated informatics system

of systems. This requirement has reopened many of the traditional and still remaining

technical challenges in dealing with the complex integration of legacy Informatics

Systems (Isystem), and the needed openness for the overall solution. Furthermore,

the trend for advanced collaborative business models, where to the extent possible

its stakeholders must dynamically join networks of distributed and heterogeneous

business partners, has raised the need for innovative solutions to cope with this

endeavor. However, systems involved in such collaborative networks are complex,

made of and maintained under distinct processes and informatics technology cultures

by different vendors, that influence them at different stages, from their conceptual

modeling to software architecture design, development, and operation. It also makes

these systems technology-dependent, causing the so-called vendor lock-in, which

presents serious obstacles to their needed crescent integration. In other words,

current approaches do not provide concise models for how such integrations can

effectively happen due to the restrictions imposed by technology dependencies.

In our research, Collaborative Networked Organizations (CNO) are the selected

domain to address challenges in tackling generalized interaction/integration

requirements among heterogeneous systems, which run under different

administrative domains.

Nowadays, the Internet’s fast emerging facilitators provide the base to create

networked collaborations, although not providing the reference architecture and

informatics solutions that are needed to decrease both their reliability risks and the

costs of maintaining their high operational quality. A novel discipline for

development of integrated informatics systems is therefore needed, with concise

models, to guide development of the involved Isystems at every node of the network,

as well as for the development of an Isystem of systems (ISoS) for their proper

support. Our proposed novel solution suggests an agnostic technological approach

which can be used to facilitate adoption of potentially competing substitutes for

Abstract

218

every Isystem within the network. Thus, it encourages creating substitutes for the

existing systems in the market, through facilitating their interaction/integration in

networks. As such our approach primarily tackles the current vendor lock-in

problem, and moves beyond it, toward a strategy to support open competitive

informatics systems landscape.

Considering today’s state of the industry, our starting problem domain

addresses the vendor lock-in as reality, where complex Isystems do not consider

existing market competitors and do not comply with an open ISoS model. Current

Isystems are typically developed as islands, including a set of sub-systems, ranging

from the hardware sensor-based cyber-physical system to high-level and complex

informatics systems (commonly referred to as software systems), that support certain

functional and nonfunctional requirements. These all perform under specific

proprietary technology and modeling approaches. Therefore, their integration is

deeply dependent on creating specific and mostly one to one adapters, which are

difficult to develop, maintain and evolve, while also generating complex and critical

dependencies among them based on their needed complex coordinated governance,

in such a heterogeneous technology setup. With the specific focus on the domain of

CNOs in product and service industry, a main target of our research is to introduce

an open model, supporting the life cycle management of complex integrated ISoS.

We therefore consider that any Isystem within an ISoS may have several market

competitors that can each properly serve the same purpose. As a design strategy for

our vendor-agnostic integrated technological solution, we support possible

replacement of any (legacy) system by another competing product, hence supporting

the substitutability of any part, a complete Isystem, or even an entire ISoS.

Our proposed and discussed research approach adopts a shift from the practiced

informatics development culture and relies more on systems thinking, mapping

directly from the requirements to implementation issues. In other words, instead of

being formulated as software parts, the implementations are defined as composites

of standard concise modeled modules, including software, or both software and

hardware if for instance composed of cyber-physical systems. The main objective is

then to contribute to a systems thinking, and formalizing a modular model that can

isolate and abstract those specificities of software development practices, currently

in place due to the lack of semantic standards. In other words, instead of software

systems, we formalize Informatics Systems (Isystem) and consider their elements as

atoms, constituting our so-called Cooperation Enabled Services (CESs), that

represent delimiters for computational business responsibilities. Our suggested

approach to systems thinking is then a strategy to facilitate enforcement of semantic

standards, and addressing open modularity based on the consolidation of the CES

Abstract

219

modules and Isystem modules. We propose and discuss the concise definition of

atomic computational responsibility, and postulate that inside such a

responsibility, the core work is centered on the body of the software development

knowledge and the software engineering.

In our proposed framework in the thesis, a CES is an atom in the making of the

Isystem molecule abstraction, to establish a supplying hierarchy of technology and

business responsibilities. This means that instead of focusing on a specific problem

domain, this research targets defining a concise model for an open multi-supplier

ISoS that is made of networked distributed computational responsibilities with

autonomous but coordinated lifecycle management. Our proposed approach

concisely models the organization’s informatics landscape (traditionally referenced

as the Information Technology or IT strategy), and represent it by a specific Isystem,

called the Isystem0 that acts as the meta-system responsible for the management of

all the organization’s deployed Isystems. According to our proposed ISoS

framework, each Isystem is then made of one or more CES elements as its

components or atomic parts, accessed through a canonical I0 interface. The I0

interface provided by each Isystem is the main entry point/service for the system.

Openness is therefore supported at two levels, namely through the Isystems and

through the CESs. Our proposed strategy is grounded in recognizing the difficulty in

establishing an open modularity framework for networking different software

components in the current informatics technology landscape, with different suppliers

that each intend to serve as the sole provider of all subsystems needed to make a

specific product. We define open in relation to the support for the substitutability

principle, and thus an Isystem or a CES is open only if it can be substituted by another

market-alternative product. That means that if any competing product exists for

certain computational responsibility, then in principle it can replace it, no matter if

is a CES in an Isystem or an Isystem in an ISoS.

While the thesis demonstrates our approach through a number of low-level

cyber-physical informatics systems, expansion of its applicability to other

applications is also discussed based on empirical knowledge, and validated by the

partial results that we have so far achieved. This scaling to higher organization’s

level, while potentially more complex, is however developed applying the same

mechanisms. An example of establishing an Isystem responsible for the organization

of data persistence, shared among different Isystems, is shown to be feasible even

though demanding a standardization effort slightly different from the existing

standards. It primarily requires enforcing the rule that the user- organizations impose

substitutability principle when preparing their large tenders. For validation purposes,

this strategy is successfully applied to the Portuguese national vehicles speed-

Abstract

220

enforcement network, as it is discussed in the thesis under the research case of the

Portuguese National Speed Enforcement Network - SINCRO.

The work in this thesis, is mostly grounded on empirical knowledge gained

through industry experience, defines a formalized model to solve the addressed

challenges, and is validated both by the scientific community through a number of

publications, and by applying them in several real industry cases. It demonstrates

how our approach succeeds in contributing to the needed changes in existing

informatics systems, considering the continuously increasing competition among the

vendors. Adoption of the needed changes in practice by the industry would however

pose several challenges. This may on one hand face the vendor resistance for

competitiveness purposes, as well as the risk of a potential rise in the costs of the

running systems, considering that the suppliers would need to invest in new

developments. Our suggested strategy for this purpose is to balance the investment

in research and validation in order to help the potential competitors having enough

sources to prepare for tenders that impose the ISoS model.

The requirements for this research are founded on a set of real industrial cases

at some private and public companies, and in collaboration with authorities who have

contributed to validation of the developed models. One important case is the

Electronic Toll Collection – ETC – initiated in 2002 with the Portuguese Brisa

Concessionaire, which was then followed from 2009 by the Brisa Innovation and

Technology. Furthermore, in 2017 our proposed approach and system is adopted by

the Portuguese A-To-Be, which is also a Brisa company, for the objective to design

and validate an open Electronic Toll Collection (ETC) informatics system. A second

set of requirements come from the HORUS case, resulted from a collaboration

between the Portuguese petroleum companies Galp and BP Portugal, to develop an

open post-payment control system for the network of forecourts. A third case, the

SINCRO, was developed together with the Portuguese National Road Safety

Authority for an open national vehicle speed-enforcement network. The fourth case

is MIELE (European Multimodal Interoperability E-services for Logistics and

Environment sustainability) which is a research project that developed the Enterprise

Collaboration Manager (ECoM) to demonstrate the Isystem for establishing an

Enterprise Collaboration Network (ECoNet) framework. More recently, the ECoNet

framework is also adopted in the context of Intelligent Transport Systems (ITS) for

a collaborative multimodal mobility payment service involving a network of

heterogeneous stakeholders in Portugal. Here the involved companies include the

Portuguese motorway concessionaires, parking lots, forecourts, banks, and mobility

authorities. The aim of this recent initiative is to provide the needed framework for

European-wide mobility under a single service contract.

221

Samenvatting

Een groeiend aantal opkomende toepassingen, zoals die met cyberfysieke

systemen, vereisen interactie / integratie en infusie van subsystemen tussen hun

componenten, die op hun beurt de ontwikkeling van een geïntegreerd

informatiesysteem van systemen vereisen. Deze vereiste heeft veel van de

traditionele en nog steeds bestaande technische uitdagingen heropend bij het omgaan

met de complexe integratie van ouderwetse Informatics Systems (Isystem) en de

benodigde openheid voor de algehele oplossing. Bovendien heeft de trend naar

geavanceerde op samenwerking gebaseerde bedrijfsmodellen, waarbij de

belanghebbenden zoveel mogelijk dynamisch moeten aansluiten bij netwerken van

verspreide en heterogene zakenpartners, de behoefte doen toenemen aan innovatieve

oplossingen om met dit streven om te gaan. Systemen die bij dergelijke

samenwerkingsnetwerken zijn betrokken, zijn echter complex, gemaakt van en

onderhouden onder verschillende processen en informatica-technologieculturen

door verschillende leveranciers, die hen in verschillende fases beïnvloeden, van hun

conceptuele modellering tot het ontwerp, de ontwikkeling en de werking van de

softwarearchitectuur. Het maakt deze systemen ook technologie afhankelijk,

waardoor de zogenaamde vendor lock-in ontstaat, wat ernstige obstakels vormt voor

hun benodigde toenemende integratie. Met andere woorden, de huidige

benaderingen bieden geen beknopte modellen voor hoe dergelijke integraties

effectief kunnen plaatsvinden vanwege de beperkingen die worden opgelegd door

technologische afhankelijkheden. In ons onderzoek zijn Collaborative Networked

Organisations (CNO) het geselecteerde gebied om uitdagingen aan te pakken bij het

aanpakken van algemene interactie / integratie-eisen tussen heterogene systemen,

die onder verschillende administratieve domeinen draaien.

Tegenwoordig vormen de snel opkomende aanbieders van het Internet de basis

om genetwerkte samenwerkingen te creëren, hoewel ze niet de referentie

architectuur en informatica-oplossingen bieden die nodig zijn om zowel hun

betrouwbaarheidsrisico's als de kosten voor het handhaven van hun hoge

operationele kwaliteit te verminderen. Een nieuwe discipline voor de ontwikkeling

van geïntegreerde informaticasystemen, met beknopte modellen, is daarom nodig

Samenvatting

222

om de ontwikkeling van de betrokken Isystems op elk knooppunt van het netwerk te

begeleiden, evenals voor de ontwikkeling van een Isystem of systems (ISoS) voor

hun juiste ondersteuning. Onze voorgestelde nieuwe oplossing draagt een

agnostische technologische benadering aan die kan worden gebruikt om de

acceptatie van potentieel concurrerende vervangers voor elk Isystem binnen het

netwerk te vergemakkelijken. Het moedigt dus aan tot het creëren van vervangers

voor de bestaande systemen op de markt door hun interactie / integratie binnen

netwerken te vergemakkelijken. Als zodanig pakt onze methode primair het huidige

probleem van vendor lock-in aan en strekt zich uit tot een strategie om een landschap

van open, concurrerend informaticasystemen te stimuleren.

Gezien de huidige staat van de industrie, behandelen we als initieel probleem

de vendor lock-in als realiteit, waarbij complexe Isystems geen rekening houden met

bestaande concurrenten op de markt en niet voldoen aan een open ISoS-model. De

huidige Isystems worden doorgaans ontwikkeld als eilanden, inclusief een reeks

subsystemen, variërend van het op sensor gebaseerde cyber-fysieke hardware

systeem tot hoogwaardige en complexe informaticasystemen (gewoonlijk

softwaresystemen genoemd), die bepaalde functionele en niet-functionele vereisten

ondersteunen. Deze werken allemaal onder specifieke eigen technologie en

modelbenaderingen. Daarom is hun integratie sterk afhankelijk van het creëren van

specifieke en meestal één-op-één adapters, die moeilijk te ontwikkelen, onderhouden

en evolueren zijn, terwijl ze ook complexe en kritieke onderlinge afhankelijkheden

genereren op basis van hun benodigde complexe gecoördineerde besturing, in een

dergelijke heterogene technologische opzet. Met de specifieke focus op het gebied

van CNO's in de product- en dienstensector, is een hoofddoel van ons onderzoek de

introductie van een open model dat de lifecycle management van complexe

geïntegreerde ISoS ondersteunt. We zijn daarom van mening dat elk Isystem binnen

een ISoS verschillende marktconcurrenten kan hebben die elk op correcte wijze

hetzelfde doel dienen. Als ontwerpstrategie voor onze leverancier-agnostische

geïntegreerde technologische oplossing pleiten we voor een mogelijke vervanging

van elk (ouderwets) systeem door een ander concurrerend product, waardoor we de

vervangbaarheid van elk onderdeel, een compleet Isystem of zelfs een hele ISoS

bevorderen.

Onze voorgestelde en besproken onderzoeksbenadering volgt de verschuiving

van de gebruikelijke informatica ontwikkeling cultuur en vertrouwt meer op

systeemdenken, waarbij de vereisten direct worden gekoppeld aan implementatie

problemen. Met andere woorden, in plaats van te worden gedefinieerd als software-

onderdelen, worden de implementaties gedefinieerd als samenstellingen van

standaard beknopte gemodelleerde modules, inclusief software, of zowel software

Samenvatting

223

als hardware als deze bijvoorbeeld bestaan uit cyber-fysieke systemen. Het

hoofddoel is vervolgens bij te dragen aan een systeemdenken en het formaliseren

van een modulair model dat de specifieke kenmerken van

softwareontwikkelingspraktijken, die momenteel van kracht zijn wegens het

ontbreken van semantische standaarden, kan isoleren en abstraheren. Met andere

woorden, in plaats van softwaresystemen, formaliseren we Informatics Systems

(Isystem) en beschouwen we hun elementen als atomen, die onze zogenaamde

Cooperation Enabled Services (CES's) vormen, die de grenzen aangeven voor

computationele zakelijke verantwoordelijkheden. Onze voorgestelde benadering van

systeemdenken is dan een strategie om de handhaving van semantische standaarden

te vergemakkelijken en te werken aan open modulariteit op basis van de consolidatie

van de CES-modules en Isystem-modules. We stellen en bespreken de beknopte

definitie van atomaire computationele verantwoordelijkheid, en betogen dat

binnen een dergelijke verantwoordelijkheid de kern van het werk gericht is op de

kennis van softwareontwikkeling en de software engineering.

In het door ons voorgestelde raamwerk in het proefschrift is een CES een atoom

bij het maken van de Isystem-molecuul-abstractie, om een toeleveringshiërarchie

van technologie en zakelijke verantwoordelijkheden tot stand te brengen. Dit

betekent dat in plaats van zich te concentreren op een specifiek probleemgebied, dit

onderzoek zich richt op het definiëren van een beknopt model voor een open ISoS

door meerdere leveranciers dat is samengesteld uit genetwerkte verspreidde

computationele verantwoordelijkheden met een autonoom maar gecoördineerd

lifecycle management. Onze voorgestelde aanpak modelleert op beknopte wijze het

informatica-landschap van de organisatie (traditioneel aangeduid als de Informatie

Technologie of IT-strategie) en vertegenwoordigt het door een specifiek Isystem, het

Isystem0 genaamd, dat fungeert als het metasysteem dat verantwoordelijk is voor

het beheer van alle door de organisatie geïmplementeerde Isystems. Volgens het

door ons voorgestelde ISoS-raamwerk is elk Isystem dan gemaakt van een of meer

CES-elementen als zijn componenten of atomaire delen, toegankelijk via een

canonieke I0-interface. De I0-interface die door elk Isystem wordt geleverd, is het

belangrijkste toegangspunt / service voor het systeem. Openheid wordt daarom op

twee niveaus ondersteund, namelijk via de Isystems en via de CES's. Onze

voorgestelde strategie is gebaseerd op het erkennen van de moeilijkheid om een open

modulariteitskader tot stand te brengen voor het netwerken van verschillende

softwarecomponenten in het huidige informatietechnologielandschap, met

verschillende leveranciers die allemaal trachten te dienen als de enige leverancier

van alle subsystemen die nodig zijn om een specifiek product te maken. We

definiëren open in relatie tot de ondersteuning van het vervangbaarheidsprincipe, en

dus is een Isystem of een CES alleen open als het kan worden vervangen door een

Samenvatting

224

ander marktalternatief product. Dat betekent dat als er een concurrerend product

bestaat voor bepaalde computationele verantwoordelijkheid, het dit in principe kan

vervangen, ongeacht of het een CES in een Isystem of een Isystem in een ISoS is.

Hoewel het proefschrift onze aanpak demonstreert via een aantal cyberfysische

informaticasystemen op laag niveau, wordt uitbreiding van de toepasbaarheid ervan

naar andere toepassingen ook besproken op basis van empirische kennis en

gevalideerd door de gedeeltelijke resultaten die we tot nu toe hebben bereikt. Deze

schaalvergroting naar een hoger organisatieniveau, hoewel mogelijk complexer, is

echter ontwikkeld met behulp van dezelfde mechanismen. Een voorbeeld van het

opzetten van een Isystem dat verantwoordelijk is voor de organisatie van gegevens

persistentie, gedeeld door verschillende Isystems, blijkt haalbaar te zijn, ook al

vereist het een standaardisering die enigszins afwijkt van de bestaande standaarden.

Het vereist in de eerste plaats handhaving van de regel dat de gebruikersorganisaties

het vervangbaarheidsprincipe opleggen bij het voorbereiden van hun grote

aanbestedingen. Voor validatiedoeleinden is deze strategie met succes toegepast op

het Portugese nationale netwerk voor snelheidshandhaving van voertuigen, zoals

besproken in het proefschrift binnen de onderzoekscasus van het Portugese

Nationale Netwerk voor Snelheidshandhaving - SINCRO.

Het werk in dit proefschrift, grotendeels gebaseerd op empirische kennis die is

opgedaan door ervaring in de branche, definieert een geformaliseerd model om de

genoemde uitdagingen op te lossen en wordt gevalideerd zowel door de

wetenschappelijke gemeenschap door middel van een aantal publicaties als door ze

toe te passen in verschillende werkelijke casussen binnen de branche. Het laat zien

hoe onze aanpak erin slaagt bij te dragen aan de noodzakelijke veranderingen in

bestaande informaticasystemen, gezien de aldoor toenemende concurrentie tussen de

leveranciers. Het toepassen van de noodzakelijke veranderingen in de praktijk door

de industrie kan echter verschillende uitdagingen met zich meebrengen. Het kan

enerzijds stuiten op de weerstand van de leverancier vanwege

concurrentiedoeleinden, anderzijds het risico lopen van een mogelijke stijging van

de kosten van de werkende systemen, aangezien de leveranciers zouden moeten

investeren in nieuwe ontwikkelingen. Onze voorgestelde strategie voor dit doel is

om de investering in onderzoek en validatie in balans te brengen om de potentiële

concurrenten te helpen zodat zij voldoende bronnen hebben om zich voor te bereiden

op aanbestedingen die het ISoS-model opleggen.

De vereisten voor dit onderzoek zijn gebaseerd op een reeks werkelijke industriële

casussen bij meerdere private en publieke bedrijven, en in samenwerking met

autoriteiten die hebben bijgedragen aan de validatie van de ontwikkelde modellen.

Een belangrijke casus is de Elektronische Tolheffing - ETC - gestart in 2002 met de

Samenvatting

225

Portugese Brisa Concessionaire, die vanaf 2009 werd opgevolgd door de Brisa

Innovation and Technology. Bovendien is in 2017 onze voorgestelde aanpak en

systeem overgenomen door het Portugese A-To-Be, dat ook een Brisa-bedrijf is, met

als doel een open informaticasysteem voor elektronische tolheffing (ETC) te

ontwerpen en te valideren. Een tweede reeks vereisten komt uit de HORUS-casus,

die voortkwam uit een samenwerking tussen de Portugese petroleummaatschappijen

Galp en BP Portugal, om een open controle systeem na betaling te ontwikkelen voor

het netwerk van tankstations. Een derde case, de SINCRO, is ontwikkeld in

samenwerking met de Portugese Nationale Autoriteit voor Verkeersveiligheid voor

een open nationaal netwerk voor handhaving van de voertuigsnelheid. De vierde

casus is MIELE (European Multimodal Interoperability E-services for Logistics and

Environment sustainability), een onderzoeksproject dat de Enterprise Collaboration

Manager (ECoM) heeft ontwikkeld om het Isystem te demonstreren voor het

opzetten van een Enterprise Collaboration Network (ECoNet) raamwerk. Meer

recentelijk is het ECoNet-raamwerk ook opgenomen in de context van Intelligent

Transport Systems (ITS) voor een op samenwerking gebaseerde betalingsdienst voor

multimodaal transport waarbij een heterogeen netwerk van belanghebbenden in

Portugal betrokken is. De betrokken bedrijven zijn onder meer de Portugese

concessiehouders van snelwegen, parkeerterreinen, tankstations, banken en

mobiliteitsautoriteiten. Het doel van dit recente initiatief is om het benodigde kader

te bieden voor Europese mobiliteit onder een enkel dienstencontract.

Samenvatting

226

Documents

UvA-DARE (Digital Academic Repository) Collaborative networks … · Freixo Guedes Osório, A. L. (2020). Collaborative networks as open Informatics System of Systems (ISoS). General