MENTORS: Monitoring Environment for System of Systems

Antonello Calabr

, Said Daoudagh

and Eda Marchetti

ISTI-CNR, Pisa, Italy

Keywords:

Ontology, Run-time Monitoring, Vulnerability Detection.

Abstract:

Context: Systems Of Systems (SoSs) are becoming a widespread emerging architecture, and they are used in

several daily life contexts. Therefore, when a new device is integrated into an existing SoS, facilities able to

efﬁcaciously assess and prevent anomalous and dangerous situations are necessary. Objective: The aim is to

deﬁne a reference environment conceived for monitoring and assessing the behavior of SoS when a new device

is added. Method: In this paper, we present MENTORS, a monitoring environment for SoS. MENTORS is

based on semantic web technologies to formally represent SoS and Monitoring knowledge through a core

ontology, called MONTOLOGY. Results and Conclusion: We deﬁned the conceptual model of MENTORS,

which is composed of two phases: Off-line and On-line, supported by a reference architecture that allows its

(semi-)automation. Validation of the proposal with real use-cases is part of future activities.

1 INTRODUCTION

Nowadays, Systems of Systems (SoSs) are becoming

an emerging widespread architecture. SoSs are used

in several daily life contexts: from our homes through

to the industrial assembly lines. Often the develop-

ment of SoS requires the integration and collabora-

tion of different ICT components or devices typically

developed by several third parties. If from the one

hand this process assures high productivity and com-

petitiveness, from the one other it exposes the SoS

to important vulnerabilities and risks. A typical con-

sequence is that each of the integrated components

could be affected by, and involuntarily propagate, the

vulnerabilities of the others included in the SoS, with

potential drastically consequences. In this situation,

when a new device or component is integrated into

an existing SoS, facilities able to efﬁcaciously assess

and prevent anomalous and dangerous situations are

therefore necessary. Among them, one commonly

adopted is the use of a monitoring system (Ullo and

Sinha, 2020), i.e., a means for the on-line analysis of

functional and non-functional properties.

Indeed, a monitor engine collects events from dif-

ferent levels from the different system components (or

sensors) and uses these data to infer complex patterns

that could represent a speciﬁc functional or non func-

https://orcid.org/0000-0001-5502-303X

https://orcid.org/0000-0002-3073-6217

https://orcid.org/0000-0003-4223-8036

tional property. The derived complex patterns repre-

sent the observed normal (or abnormal) behavior of

the monitored system (or its components). There-

fore, the monitor is able to: i) collect and analyze data

coming from the different SoS sources (e.g., sensors,

components or devices); ii) assess the run time SoS

(components or devices) behaviour; iii) promptly rise

up alarms in case of violations; and, iv) put in place

countermeasures if necessary.

However, even if notably efﬁcient and effective,

the design, implementation, and management of a

monitoring system inside an SoS environment may

involve the participation of different stakeholders

such as SoS domain experts, device developers, or

monitoring experts. Thus, due to the intrinsic com-

plexity of the scenario, monitoring the integration of

new devices (or components) in different SoS envi-

ronments can result in a complex and costly activ-

ity (Rastogi et al., 2020). One of its main critical-

ities is the lack of a common understanding: ex-

perts of SoS domain could ignore the peculiarities

of monitoring activity and vice versa. Thus, this pa-

per wants to move a step ahead in this direction, by

joining the different deﬁnitions of the SoS and moni-

toring context into a unique structural representation.

For this, we conceived a smart and efﬁcient moni-

toring processes for SoS, called MENTORS - Mon-

itoring ENviromenT fOR Sos. MENTORS can pro-

vide a support for all the stakeholders involved in the

monitoring process with the purpose of: i) lowering

Calabrò, A., Daoudagh, S. and Marchetti, E.

MENTORS: Monitoring Environment for System of Systems.

DOI: 10.5220/0010658900003058

In Proceedings of the 17th International Conference on Web Information Systems and Technologies (WEBIST 2021), pages 291-298

ISBN: 978-989-758-536-4; ISSN: 2184-3252

291

down costs of developing and setting up the moni-

toring environment, i.e., allowing the use of available

monitor engines (e.g., GLIMPSE (Bertolino et al.,

2011; Barsocchi et al., 2018)) without the necessity

to implement ad hoc solutions; ii) improving qual-

ity control by smart and effective rules speciﬁcation

and encoding; iii) increasing ﬂexibility and produc-

tivity by automating the monitoring process through

a reference architecture so as to make the moni-

tor designers agnostic of the domain speciﬁc chal-

lenges (see for instance (Palumbo, 2018)); and iv) in-

crease the interoperability by using standardized and

domain independent speciﬁcation technologies (e.g.,

OWL (Motik et al., 2012) for the Ontology descrip-

tion, and RuleML (Boley et al., 2001) or Drools

for

instantiating rules).

Outline: Section 2 reports related work, whereas

the conceived monitoring process for the SoS, com-

posed of two main phases (off-line and On-line) is in-

troduced in Section 3. Section 4 illustrates the deﬁni-

tion of standardized and domain independent speciﬁ-

cation of the SoS and monitoring concepts. A prelim-

inary structure of the reference architecture allowing a

(semi-)automation of the proposed process is reported

in Section 5. Finally, Section 6 concludes the paper

and reports future work.

2 RELATED WORK

At state of the practice, different run time solutions

are currently available in many domains: trafﬁc mon-

itoring systems (Won, 2020), indicators on the control

panel of a car (Fotescu et al., 2020), airplane or elec-

tronic device (Hidayanti, 2020), monitors for phys-

iological conditions of patients in a hospital (San-

tos et al., 2020) or systems for controlling complex

large-scale systems such as airports, railways or in-

dustrial plants (Bhamare et al., 2020). Usually, all the

monitoring solutions address two main challenges:

i) ﬁnding very powerful, concise and unambiguous

speciﬁcation languages able to express the properties

to be validated (Khan et al., 2021); ii) deﬁning ef-

ﬁcient mechanisms to assess conformity of the sys-

tem against these properties or contracts (Burns et al.,

2018). In line with the current research, the aim of this

work is to advance the state of practice of the monitor-

ing process, by conceiving an easy to use and effective

solution for the application of the monitoring activ-

ity inside SoS. Indeed, MENTORS can enhances the

existing monitoring approaches for: 1) promptly ris-

https://www.drools.org/

ing warnings and detecting failures, and for enabling

system reconﬁguration, reliable and trustworthy exe-

cution; 2) capturing, inferring and analysing complex

events, so to allow the detection of critical problems,

failures and security vulnerabilities; and 3) validat-

ing the trust and security level of run-time behavior

of SoS and its devices.

3 CONCEPTUAL MODEL AND

PROCESS

From a conceptual point of view, the monitoring pro-

cess presented in this paper is based on a structural

representation of the concepts and knowledge about

the SoS, devices and monitoring environments.

As schematized in Figure 1, the MENTORS mon-

itoring process is structured into two different phases:

i) Off-line phase, in which the concepts and the

knowledge about the different SoS and the available

devices are organized and integrated in a structural

speciﬁcation, and monitoring rules deﬁned; ii) On-

line phase, in which the monitoring activities are ex-

ecuted, results collected and inferences about the ob-

served behavior and possible rules improvements de-

ﬁned.

Speciﬁcally, as reported in Figure 1, during the

former phase the conceptual steps are:

• SoS Speciﬁcation & Monitoring Speciﬁcation:

SoSs are widespread adopted in several applica-

tion domain, each having its speciﬁc needs and

challenges (Raman and D’Souza, 2019). How-

ever, at the state of the practice there is not

a common knowledge-base for collecting into a

unique environment the SoS and monitoring re-

quirements, speciﬁcations, architectural design,

and the set of existing or conceivable monitoring

rules useful for the assessment or quality improve-

ment (Vierhauser et al., 2016). This kind of infor-

mation is still on the hands of a few experts and it

is not easily shareable between the different stake-

holders. As reported Figure 1, MENTORS pro-

vides a solution for this lack, i.e., a continuously

updatable structural representation of the research

and practical knowledge about SoS and the moni-

toring anemometers.

• SoS & Monitoring Ontology: At the state of

the practice, one of the recognized means for

knowledge representation and environmental data

modeling is the use of ontologies (Motik et al.,

2012). They provide a common vocabulary use-

ful for modeling and understanding speciﬁc do-

mains by capturing knowledge in a structured and

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

292

Figure 1: MENTORS: Conceptual Model.

formal way. As in Figure 1, MENTORS orga-

nizes, revises and structures the available knowl-

edge by means of an ontology (Berners-Lee et al.,

2001) called MONTOLOGY - MONitoring on-

TOLOGY (see Section 4).

• Abstract Monitoring Rules: In the context of

SoS, and considering in particular the rules def-

inition, even if traditional performance indicators

could be still relevant, the dynamic evolution and

complexity of SoS require the availability of suit-

able rules, able to take into account also events

risen by the SoS context in which the device (or

its components) is included. Consequently, suc-

cessful rules deﬁnition requires a deep knowledge

of the SoS domain and its environment as well

as monitoring behavior and management. By ex-

ploiting the MONTOLOGY structure, the pro-

posal of this paper provides both: i) a common

evolving rules deﬁnition, able to improving qual-

ity control and increasing ﬂexibility and produc-

tivity of the monitoring process; ii) means for

easily instrumenting the selected set of rules ac-

cording to the selected SoS domain needs and at-

tributes.

Crossing from Off-line phase to On-line phase, the

Abstract Monitoring Rules, generated through

MONTOLOGY, will be instantiated for a speciﬁc rule

language understandable by the selected Monitoring

component, and enacted for monitoring the SoS and

New Device during the On-line phase. Therefore, dur-

ing the On-line phase, the conceptual steps are:

SoS & New Device Monitoring: The instantiated

rules are used to monitor the new device behavior in-

side a target SoS. During this activity, possible rule

violations are detected and possibly managed.

Results & Analysis: The monitored data are then an-

alyzed so as to infer new knowledge about the SoS

or Device behavior, or to enrich the MONTOLOGY

contents.

In the remainder of this paper, details about MON-

TOLOGY and the MENTORS reference architecture

will be provided in Section 4 and Section 5.3, respec-

tively. It is out of the scope of the paper discussing the

validation of the proposal, which is part of our future

work.

4 MONTOLOGY: MONITORING

ONTOLOGY

In this section, we introduce our core ontology (called

MONTOLOGY) for supporting the realization of

MENTORS. We ﬁrstly present the development pro-

cess in Section 4.1, and then we brieﬂy describe its

main modules in Section 4.2.

4.1 Process for Developing

MONTOLOGY

The process adopted for developing MONTOLOGY

is based on (Gharib et al., 2021), and it follows the

MENTORS: Monitoring Environment for System of Systems

293

Figure 2: Process for Developing MONTOLOGY (adapted from (Gharib et al., 2021)).

ﬁve principles proposed in (Gruber, 1995) (i.e., clar-

ity, coherence, extendibility, minimal encoding bias,

and minimal ontological commitment).

As depicted in Figure 2, the process is composed

of ﬁve main steps:

1. Scope & Objective Identiﬁcation (Step 1 ) where

the scope and the purposes of the ontology and

its intended end-users are identiﬁed. In our case,

the purpose is to allow any possible stakeholder

to deﬁne, for every speciﬁc SoS domain, a set of

effective and well-deﬁned monitoring rules able

to reveal the vulnerabilities and or problems that

a new device integration could arise.

2. Knowledge Acquisition (Step 2 ) where the

knowledge needed for the realization of the in-

tended ontology is collected. During this step,

monitoring and SoS experts have been involved

both for the identiﬁcation of the concepts and their

relationships, as well as for capturing monitor-

ing and SoSs requirements. Analysis of the avail-

able literature concerning SoS and monitoring has

been also performed (de Almeida et al., 2020;

Silva et al., 2015).

3. Conceptualization (Step 3 ) where the core ontol-

ogy (i.e., MONTOLOGY) for supporting moni-

toring process is derived. MONTOLOGY is com-

posed of 13 concepts: 8 coming from SoS do-

main, and 5 coming from monitoring domain (see

Section 4.2 for more details).

4. Implementation (Step 4 ) where the conceptual-

ized ontology is codiﬁed into a formal language.

This requires an environment that guarantees (1)

checking lexical and syntactic errors so as to im-

plement an error-free ontology, and (2) an auto-

mated reasoner for detecting inconsistencies and

redundant knowledge. For MONTOLOGY im-

plementation, Prot

has been selected be-

cause: it is an open-source environment allowing

creating, modifying, visualizing and checking the

consistency; and it relies on SPARQL

(Protocol

and RDF Query Language) for knowledge extrac-

tion.

5. Validation (Step 5 ) where the validation of

MONTOLOGY is performed to assure that it

https://protege.stanford.edu/

https://www.w3.org/TR/rdf-sparql-query/

meets the needs of its usage. For this purpose,

speciﬁc SPARQL queries are being deﬁned to

evaluate the MONTOLOGY level of detail.

4.2 MONTOLOGY Modules

MONTOLOGY (MONitoring onTOLOGY) is com-

posed of two modules: System of Systems (SoS)

module (yellow classes in Figure 3) and Monitoring

module (green classes in Figure 3). Due to space lim-

itation, we just give some details about the two mod-

ules.

System of Systems (SoS) Module. It models SoS

and its components, as well as the relationship among

them. As in Figure 3, a SystemOfSystems is a col-

lection of Devices that represent the object of the

monitoring activities. Each Device is composed of

a speciﬁc set of Components. SoS and Components

are related to as set Attributes: SoS is connected to

SoSAttribute through the hasSoSAtribute relationship,

whereas Component is connected to ComponentAt-

tribute through the haCompAttribute relationship. As

in the ﬁgure, Attribute is connected to both Measure

and Metric concepts, and it is a super-class of SoSAt-

tribute and ComponentAttribute. Through this hier-

archy, these sub-classes can be connected to Measure

and Metric concepts as well.

Monitoring Module. It aims at modelling moni-

toring concepts and relationship between them. The

core class of Monitoring module is the Rule, which

is the atomic observable concept within MENTORS.

Indeed, the Monitor observes rules organized in Cal-

endar, which is an ordered set of rules. Each Calen-

dar is able to validate a speciﬁc Skill at run-time, i.e.,

during the on-line phase depicted in Figure 1. Skill

is speciﬁed as a set of Requirements, each veriﬁed

through a speciﬁc Rule (see the veriﬁesRequirement

relationship).

The two main modules are then connected each

other as following: (1) each SystemOfSystems de-

ﬁnes a set of Skill, each related to a speciﬁc Compo-

nent; (2) the core element of Monitoring module, i.e.,

Rule concept, is deﬁned through a set of Attributes.

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

294

Figure 3: Overview of MONTOLOGY.

5 MENTORS: ACTORS, USE

CASES AND ARCHITECTURE

In this section, we describe MENTORS, a monitor-

ing environment for System of Systems (SoS). We

ﬁrstly illustrate the main actors involved in MEN-

TORS; then, we describe the supported uses cases; ﬁ-

nally, we present the conceived MENTORS reference

Architecture.

5.1 Actors

As anticipated in the introduction, the monitoring pro-

cess may involves several stakeholders as schema-

tized in Figure 4 Box A . In particular, the main actor

is MENTORS user who is the generic actor interact-

ing with MENTORS framework. This actor can be

in turn specialized into different actors. The Business

Manager, who is the user of the monitoring system.

She or he is in charge of the speciﬁcation of the mon-

itoring needs (e.g., rules) as well as the administra-

tion and management of the monitoring data analy-

sis and alerts. The Learning System that represents

an autonomous system able to analyze the collected

monitoring data, so as to infer new knowledge (e.g.,

new rules, concepts or relationships) for improving

MONTOLOGY. The CEP Programmer who is an ex-

pert of a speciﬁc monitoring system, and she or he is

in charge of instantiating the rules subset into a pre-

cise rules language. The SoS Expert who is expert

of the SoS domain, its constituent parts and their at-

tributes. The Ontology User who has the knowledge

of the ontology concepts and management, and she

or he is the responsible to conceptualize, to imple-

ment and to maintain MONTOLOGY. This actor can

be specialized into Device Expert. They are experts

of a speciﬁc device, and he or she knows the Device

constituent parts, their needs and their attributes.

5.2 Use Cases

The use cases were guided by the conceptual model

introduced in Section 3. To better clarify the roles

of each actor, in Figure 4 Box

B the main function-

alities provided by MENTORS are reported. In par-

ticular, Ontology User and Learning System use the

Populate Ontology feature for specifying his or her

knowledge of the SoS or the device. More precisely,

Ontology User can populate MONTOLOGY with in-

MENTORS: Monitoring Environment for System of Systems

295

Figure 4: MENTORS: Actors and Use Cases.

dividuals and assertions about the SoS or the device.

This feature includes also the possibility to modify the

content of MONTOLOGY or extend it with already

existing ontologies. The Ontology User and the Busi-

ness Manager have then the possibility to Navigate

ontology, so as to explore the already existing knowl-

edge and to perform speciﬁc queries. Additionally,

Business Manager, through Select rules subset can

navigate the MONTOLOGY and can specify the most

suitable rules to be monitored. The selected rules will

then be instantiated by the CEP programmer through

Instantiate rule feature so as to be observed by se-

lected monitoring infrastructure. In particular, Moni-

toring feature is in charge of checking if the instanti-

ated rules are respected or not. This functionality is

also in charge of the storage of the monitoring data so

as to let the Business Manager to analyze them.

5.3 Proposed Architecture

Our reference architecture is depicted in Figure 5,

which is an abstract architecture that can be cus-

tomized with different real tools. MENTORS refer-

ence architecture is composed of the following com-

ponents:

(1) GUI provides a user-centric & user-friendly

graphical interface that allows MENTORS Users

to interact with MENTORS for performing all

the available functionalities previously introduced

and reported in Figure 4 Box B .

(2) Monitoring component is the core of the analysis

of the system execution implementing the Mon-

itoring and Instantiate rules features described

in Section 5.2. It includes the Complex Event

Processor (CEP) (de Almeida et al., 2020) sub-

component that is in charge of inferring simple

and complex pattern from the events captured dur-

ing the run time. An event, is a snapshot of a

change of the status within a system. Events are

captured by Probes, which are piece of code in-

jected within the device to monitor. Probes are n

charge to put on an envelope the change of sta-

tus occurred within the component monitored and

sent it to the monitoring. The received data will

be matched with the instantiated rules and results

will be stored into the Executed Data DB for fur-

ther analysis.

(3) Instantiated Rules DB contains the rules selected

by Business Manager through the GUI, and in-

stantiated by the CEP Programmer. The rules are

translated into the language of the CEP. In our

case, the Drools Language

has been used for the

scope.

(4) Executed Data DB stores data derived from sys-

tem execution, and it makes those data available

for further analysis.

(5) KB Manager implements Populate ontology,

Navigate Ontology and Select rules subset fea-

tures (see Section 5.2). Speciﬁcally, users can

manage the ontology through the GUI, while

the Learning System can access through speciﬁc

API. As in Figure 5, KB Manager interacts with

the Knowledge Base component for updating and

managing MONTOLOGY. KB Manager can be

considered as a middle-ware between: the known

Knowledge Base, the observed Monitoring and

Details about Drools Language can be found at: https:

//www.drools.org/

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

296

Figure 5: MENTORS: Supporting Predictive Monitoring Architecture.

the inferred Learning System.

(6) Knowledge Base allows the MONTOLOGY

speciﬁcation and update. In particular, MON-

TOLOGY is represented as an RDF (Manola and

Miller, 2004) graph, which is saved in a triple

store on which it is possible to perform queries.

(7) Learning System implements the Infer new

knowledge and contributes to the Populate On-

tology feature (see Section 5.2). Speciﬁcally,

this component, through a reasoner, analyzes the

Knowledge Base data and the information col-

lected in the Executed Data DB, for both perform-

ing consistency checks and inferring new emerg-

ing knowledge. The results of this analysis are

provided to Knowledge Base component through

KB Manager. This component can be instantiated

with different reasoners available in literature

such as Openllet

6 CONCLUSIONS

In this paper, we have introduced MENTORS, a refer-

ence monitoring environment speciﬁcally conceived

for SoS. In particular, MENTORS is targeting the sit-

uation in which a new device or component is inte-

An updated list of the currently

available reasoners can be found in:

https://www.w3.org/2001/sw/wiki/OWL/Implementations

https://github.com/Galigator/openllet

grated into an existing SoS, so as to assess and pre-

vent anomalous and dangerous behaviour of both the

device and the SoS. We ﬁrstly conceptualized MEN-

TORS as process consisting of two main parts, Off-

line and On-line. The former is supported by an on-

tological representation of the SoS and Monitoring

domains through MONTOLOGY ontology. This is

a core ontology useful for developing and deriving

meaningful rules that can be monitored, and it can

be exploited also for inferring new knowledge about

the SoS. The latter consists of monitoring the con-

ceived rules so as to promptly identify misbehaviour

in terms of run-time violations. To this purpose, we

have also presented a reference architecture that can

be customized with different tools. As future work,

we are planning to thoroughly validate MENTORS

within an ongoing European Project. This validation

could improve both MONTOLOGY and MENTORS

reference architecture for supporting new functional-

ities.

ACKNOWLEDGEMENTS

This work was partially supported by Cyber-

Sec4Europe H2020 Grant Agreement No. 830929

and the EU H2020 BIECO project Grant Agreement

No. 952702.

MENTORS: Monitoring Environment for System of Systems

297

REFERENCES

Barsocchi, P., Calabr

o, A., Ferro, E., Gennaro, C.,

Marchetti, E., and Vairo, C. (2018). Boosting a low-

cost smart home environment with usage and access

control rules. Sensors, 18(6):1886.

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

Semantic Web. Scientiﬁc American, 284(5):28–37.

Bertolino, A., Calabr

o, A., Lonetti, F., and Sabetta, A.

(2011). GLIMPSE: a generic and ﬂexible monitoring

infrastructure. In Giandomenico, F. D., editor, Pro-

ceedings of the 13th European Workshop on Depend-

able Computing, EWDC ’11, Pisa, Italy, May 11-12,

2011, pages 73–78. ACM.

Bhamare, D., Zolanvari, M., Erbad, A., Jain, R., Khan, K.,

and Meskin, N. (2020). Cybersecurity for industrial

control systems: A survey. computers & security,

89:101677.

Boley, H., Tabet, S., and Wagner, G. (2001). Design ra-

tionale for ruleml: A markup language for seman-

tic web rules. In Cruz, I. F., Decker, S., Euzenat,

J., and McGuinness, D. L., editors, Proceedings of

SWWS’01, The ﬁrst Semantic Web Working Sympo-

sium, Stanford University, California, USA, July 30

- August 1, 2001, pages 381–401.

Burns, M., Griffor, E., Balduccini, M., Vishik, C., Huth,

M., and Wollman, D. (2018). Reasoning about smart

city. In 2018 IEEE International Conference on Smart

Computing (SMARTCOMP), pages 381–386.

de Almeida, V. P., Bhowmik, S., Lima, G., Endler, M., and

Rothermel, K. (2020). Dscep: An infrastructure for

decentralized semantic complex event processing. In

2020 IEEE International Conference on Big Data (Big

Data), pages 391–398. IEEE.

Fotescu, R.-P., Constantinescu, R., Alexandrescu, B., and

Burciu, L.-M. (2020). System for monitoring the

parameters of vehicle. In Advanced Topics in Op-

toelectronics, Microelectronics and Nanotechnologies

X, volume 11718, page 117180A. International Soci-

ety for Optics and Photonics.

Gharib, M., Giorgini, P., and Mylopoulos, J. (2021). Copri

v.2 — a core ontology for privacy requirements. Data

& Knowledge Engineering, 133:101888.

Gruber, T. R. (1995). Toward principles for the design of

ontologies used for knowledge sharing? International

Journal of Human-Computer Studies, 43(5):907–928.

Hidayanti, F. (2020). Design and application of monitor-

ing system for electrical energy based-on internet of

things. Helix, 10(01):18–26.

Khan, S., Nazir, S., Garc

ıa-Magari

no, I., and Hussain, A.

(2021). Deep learning-based urban big data fusion

in smart cities: Towards trafﬁc monitoring and ﬂow-

preserving fusion. Computers & Electrical Engineer-

ing, 89:106906.

Manola, F. and Miller, E. (2004). RDF Primer. W3C Rec-

ommendation, WWW Consortium. http://www.w3.

org/TR/rdf-primer/.

Motik, B., Patel-Schneider, P. F., and Parsia, B. (2012).

OWL 2 Web Ontology Language structural speciﬁ-

cation and functional-style syntax (second edition).

W3C recommendation, World Wide Web Consortium.

Palumbo, F. (2018). Leveraging smart environments for

runtime resources management. In Software Quality:

Methods and Tools for Better Software and Systems:

10th International Conference, SWQD 2018, Vienna,

Austria, January 16–19, 2018, Proceedings, volume

302, page 171. Springer.

Raman, R. and D’Souza, M. (2019). Decision learning

framework for architecture design decisions of com-

plex systems and system-of-systems. Systems Engi-

neering, 22(6):538–560.

Rastogi, V., Srivastava, S., Mishra, M., and Thukral, R.

(2020). Predictive maintenance for sme in indus-

try 4.0. In 2020 Global Smart Industry Conference

(GloSIC), pages 382–390.

Santos, M. A., Munoz, R., Olivares, R., Rebouc¸as Filho,

P. P., Del Ser, J., and de Albuquerque, V. H. C. (2020).

Online heart monitoring systems on the internet of

health things environments: A survey, a reference

model and an outlook. Information Fusion, 53:222–

239.

Silva, E., Batista, T., and Oquendo, F. (2015). A mission-

oriented approach for designing system-of-systems.

In 2015 10th System of Systems Engineering Confer-

ence (SoSE), pages 346–351. IEEE.

Ullo, S. L. and Sinha, G. R. (2020). Advances in smart en-

vironment monitoring systems using iot and sensors.

Sensors, 20(11).

Vierhauser, M., Rabiser, R., Gr

unbacher, P., Seyerlehner,

K., Wallner, S., and Zeisel, H. (2016). Reminds : A

ﬂexible runtime monitoring framework for systems of

systems. Journal of Systems and Software, 112:123–

136.

Won, M. (2020). Intelligent trafﬁc monitoring systems

for vehicle classiﬁcation: A survey. IEEE Access,

8:73340–73358.

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

298