RoSA: A Framework for Modeling Self-Awareness in Cyber-Physical Systems

The role of smart and autonomous systems is becoming vital in many areas of industry and society. Expectations from such systems continuously rise and become more ambitious: long lifetime, high reliability, high performance, energy efficiency, and adaptability, particularly in the presence of changing environments. Computational self-awareness promises a comprehensive assessment of the system state for sensible and well-informed actions and resource management. Computational self-awareness concepts can be used in many applications such as automated manufacturing plants, telecommunication systems, autonomous driving, traffic control, smart grids, and wearable health monitoring systems. Developing self-aware systems from scratch for each application is the most common practice currently, but this is highly redundant, inefficient, and uneconomic. Hence, we propose a framework that supports modeling and evaluation of various self-aware concepts in hierarchical agent systems, where agents are made up of self-aware functionalities. This paper presents the Research on Self-Awareness (RoSA) framework and its design principles. In addition, self-aware functionalities abstraction, data reliability, and confidence, which are currently provided by RoSA, are described. Potential use cases of RoSA are discussed. Capabilities of the proposed framework are showcased by case studies from the fields of healthcare and industrial monitoring. We believe that RoSA is capable of serving as a common framework for self-aware modeling and applications and thus helps researchers and engineers in exploring the vast design space of hierarchical agent-based systems with computational self-awareness.


I. INTRODUCTION
The number of Cyber-Physical Systems (CPSs) with embedded sensors and actuators is growing exponentially [1], [2].These systems enable a wide range of applications like automated manufacturing plants [3], telecommunication systems [4], [5], autonomous driving [6], traffic control [7], smart grids [8], and mobile health monitoring systems [9] just to name a few examples.No matter the actual application, The associate editor coordinating the review of this manuscript and approving it for publication was Mark Kok Yew Ng .
CPSs connect their physical environment (the real world) with the digital (i.e., cyber) space under ever-increasing expectations and requirements [10].Some system properties that are needed for meeting application requirements are adaptivity, autonomy, reliability, robustness, long lifetime, high performance, and energy efficiency.A controlled balance among those sometimes contradictory properties is a must as well [11].
Because of these requirements, a complex interaction between a CPS and its environment is necessary.The system needs to know how its environment behaves and how its own actions may affect the environment.Besides, a CPS may have limited resources and need to consider system properties like the growing process variability, thermal limitations, and wear-out effects of System on Chip (SoC) solutions.These could lead to an unbalanced lifetime, overheating, hotspots, rapid aging, and under-utilization [12]- [14], which requires sophisticated resource management.Thus, a comprehensive assessment of the system's state and that of its environment is needed and allows prediction of future events, better planning of actions, and hence optimized operation [15].
Computational Self-Awareness (CSA) has been studied in a wide range of applications [16]- [18], and proved to be a key enabler of efficient resource management in different domains (e.g., sensor networks [19] and health monitoring systems [20]).It has also been proposed to tackle the challenges of comprehensive assessment in different CPSs [18], [21]- [24].However, the community researching on self-awareness is fractioned, and research proceeds rather slow.To the best of our knowledge, so far, there is no satisfactory common tool to speed up research on selfawareness.We propose a software framework, Research on Self-Awareness (RoSA), 1 for modeling self-awareness concepts and applications.RoSA is based on a hierarchical agent-based model and provides facilities to implement, adapt, customize, and evaluate self-aware applications.The framework itself is a three-fold software engineering exemplar [25]: it can be used in the engineering process to model applications as well as it serves as a testbed and library (i.e.infrastructure for conducting research and a set of reusable models or code, respectively).We hope that RoSA can serve as a common framework for the community to explore uncharted aspects of self-awareness and speed up development in the field.
This paper provides an overview of the framework, how it works and how it can be used.The applicability and flexibility of RoSA are demonstrated by two case studies from the fields of human health monitoring [26]- [28] and industrial machine monitoring [29]- [31].The main contributions of the paper are: 1) we propose a framework, RoSA, which facilitates the modeling and evaluation of self-awareness concepts by means of modeling self-aware applications as hierarchical agent systems and modeling agents based on self-aware functionalities; 2) we provide an initial set of self-aware functionalities, namely abstraction, data reliability, and confidence, implemented in RoSA; and 3) we describe use cases for RoSA-based modeling, whose utility has been proven by our case studies.The rest of the paper is organized as follows.Section II highlights the motivation and research challenges of this study.Section III then summarizes the state of the art in the field of CSA with interest in modeling and implementation frameworks.Section IV introduces terminology as well as the architecture and implementation of RoSA.Possible use cases of the framework are discussed in Section V. Self-aware functionalities that are currently available in RoSA are described in Section VI, whereas Section VII presents case studies, which use those functionalities and general RoSA facilities.Section VIII discusses which lessons have been learned while developing this framework, and finally, Section IX concludes the paper.We include a list of abbreviations at the end of the paper for the reader's reference.

II. MOTIVATION AND RESEARCH CHALLENGES
CSA is a hot topic, and some approaches that make CPSs intelligent exist [32], [33].Still, the field is widely unexplored, and many aspects of self-awareness are yet to be researched.
While studying open questions of self-awareness (case studies in Section VII), we made an effort to implement experiments in a sustainable modular fashion.It was possible to separate a runtime system from application code and identify reusable components by systematizing our experimental codebases.A retrospective realization showed that much work could have been saved if it were for a framework that provided the application-agnostic parts of our custom code.
We also realized that lacking a reusable framework is not a specific issue for us but must be a general one.Despite being a hot topic, techniques and methods around self-awareness are developed at a moderate pace and lack convergence.A major obstacle that is to be overcome is the high cost (mostly development time) of implementing self-aware systems.Lacking a common framework makes each system to be developed from scratch.This results in a considerable amount of work being done redundantly, inefficiently, and uneconomically.Using a common framework would enable cooperation and synergy among researchers and practitioners from a diverse spectrum of expertise.
So we set off to make a framework based on our experience and considering the following goals: • use a compositional application model, • provide reusable features and facilitate customization, • support both simulation and deployment of applications, • have a low-footprint realization to enable the framework in resource-constrained Embedded Systems (ESs), • make a future-proof and sustainable framework (e.g., standard and stable technology, platform independence, low overhead, open architecture).
Selecting a proper architecture and implementation fitting our goals was a fundamental question.We concluded with a hierarchical agent-based architecture, whose details are discussed in Section IV-B.As none of the available agent-based frameworks can fully cover our goals (detailed evaluation in Section III-F), we implemented RoSA as a new framework.
Identifying and implementing self-aware functionalities so that they can be reused in different applications is a storehouse of challenges.We spent the most time with functionalities abstraction, data reliability, and confidence, whose reusable implementations are featured in RoSA.

III. BACKGROUND AND RELATED WORK
Our work is motivated by the ever-growing importance and relevance of self-awareness in CPSs and SoCs.In Section III-A, we give a short inside of Autonomic Computing (AC), while we throw a bridge to Self-Awareness in Section III-B.Since we propose a modeling framework for self-aware systems to facilitate collaboration in the field and go beyond the state of the art, we discuss existing self-aware architectures in Section III-C and review frameworks implementing self-aware systems in Section III-D.For the technical background of our proposed implementation, decentralized architectures are reviewed in Section III-E and available implementations of our choice of architecture, agent-based frameworks, in Section III-F.

A. AUTONOMIC COMPUTING
Smart systems require high degrees of automation and autonomy [34].The word autonomy originates from ancient Greece and means to be self-governing, in other words, to have own laws [35].In the context of computer systems, the concept of autonomy came up in the 1990s and was inspired by biological systems [36].Both academia and industry started some initiatives at that time [35].
As often, very early attempts were made in the military field.Defense Advanced Research Projects Agency (DARPA) had a project in which they developed a communication and location device for soldiers [37], [38].Soldiers could give information about the situation of themselves and their environment.Together with locating and sensing abilities of the device, relevant details on the battlefield were spread between the soldiers.
Besides, in the 1990s, the National Aeronautics and Space Administration (NASA) started projects such as Mars Path Finder and Deep Space 1.The goal of these projects was that space crafts should become more autonomous to operate, navigate, and manage deep-space probes with less intervention of humans [39].The fact of becoming more autonomous was important because remote control of these space crafts is associated with a clearly noticeable delay and therefore was highly impractical.
The complexity and dynamic changing environments call for autonomic systems [35].In 2001, the International Business Machines Corporation (IBM) declared that the complexity of Information Technology (IT) systems would be one of the biggest challenges for the progress of the industry in the coming decades [40].To make computer systems autonomous and having less need for human interventions, IBM started the AC initiative and introduced five levels of maturity: basic, managed, predictive, adaptive, and autonomic [41]- [44].The lowest level (basic) describes a system that is managed by highly skilled staff which monitor these systems and manually modify them based on the gathered information [37].In contrast, the highest level describes fully autonomic systems (or applications) that totally manage themselves in order to fulfill high-level goals which could be given by humans [36].In other words, an AC system manages itself according to high-level objectives given by humans [45].
Furthermore, IBM introduced in [42] the four self-* properties of AC (often referred to as ''self-chop'' [10], [37]): • self-configuration (autonomous configuration, such as adjusting parameters or changing software, in order to fulfill high-level goals), • self-healing (autonomous detection and diagnostic for discovering problems and trying to fix them autonomously), • self-optimization (autonomous resource usage optimization), and • self-protection (autonomous protection against malicious attacks and unintentional misapplication by the system's user).
These self-* properties (in details described in [44], [46]) are the most cited ones in the AC domain, but the number of them has continuously grown; for the most prominent examples, we refer to [35], [36].

B. SELF-AWARENESS
Self-awareness, which is one of the self-* properties, was proposed originally in the IBM initiative on autonomic computing [44], [47].Computational reflection and self-awareness are very close to each other.Computational Reflection is the ability of a system to reason about its capabilities, limitations and resources [45].A self-aware system observes itself as well as its environment and changes its behaviour according to the observations it has made.Thus, self-awareness could also be called computational reflection [48], [49].A self-aware computer system needs sensors to sense the internal as well as the external environment and actuators to self-adapt to the changing environment [36].In an effort to improve flexibility and adaptivity of systems, the self-* properties are organized into a hierarchy with self-awareness and context-awareness at the base (Figure 1).In other words, a system has to be self-aware to be self-adaptive (or autonomous).A correlation between the usage of self-* properties and the quality of complex software systems has been shown in [50].
Self-awareness has recently moved up in prominence.Initially, it was at the bottom of the self-* pyramid (Figure 1) as a supporting feature for more advanced adaptive behavior.Recently, self-awareness is used quite often to encompass all relevant self-* properties, including self-adaptiveness.The pyramid has been turned upside down because of the realization: self-awareness is not just a collection of state variables.It must include the goals of the system and properly reflect the effects of actions on itself and the environment.However, in contrast to other self-* solutions or AC, a fully self-aware system operates not only reactively but proactively.This means that such a system needs to be able to learn, make conclusions, and act accordingly [51].
The different aspects of self-awareness -like selfmonitoring, situation-awareness, and attention -have been shown to be essential for efficient embedded CPSs [15], [52], [67]- [71].Self-monitoring is the activity of sampling system properties (e.g., chip temperature [71]) as well as transforming and filtering sampled data in a system-specific way (see the self-aware functionality abstraction in Section VI-A).Situation-awareness assesses the observations and gives significance to data.On the other side, attention balances the competing tasks of data collection, processing, and responses under tight resource constraints by dynamically prioritizing goals and tasks.The overall system performance is monitored in a dynamically changing environment by means of self-awareness.
It has already been shown that self-awareness can help solve many problems of CPSs and SoCs.Furthermore, different aspects of self-awareness are used to make CPSs smarter [32], [33], [72].However, the development of self-aware systems and related methods is still a difficult and tedious process.Moreover, efforts are fragmented among different communities because of the lack of a common framework to explore self-awareness and its properties.We propose a framework, RoSA, to overcome that obstacle.RoSA is based on principles and methods that have been published in literature but have not been combined before.The next few paragraphs overview various works that are related to RoSA.

C. REFERENCE ARCHITECTURES FOR SELF-AWARENESS
There exist several reference architectures which concern systems related to CSA [51].One of them is the MAPE-K loop (an autonomic control loop coming from the AC field [42], [44])), which stands for Monitor, Analyze, Plan, Execute, and Knowledge.Information is collected from sensors in the monitor phase, and the gathered information is analyzed in the analyze phase.Subsequently, the plan-and execute phases are about planning and executing actions in order to fulfill goals or solve problems [51].All these four phases share one common aspect: knowledge about the context, the execution environment and the hardware infrastructure.The MAPE-K loop is very similar to the Observe-Decide-Act (ODA) loop we have implemented (Section IV-B3).
The Learn, Reason, Act architecture is a model-based learning and reasoning loop (LRA-M loop) [73].The architecture describes a self-aware computing system that is driven by its goals and its observations collected as empirical data.The collected data are used in an ongoing learning process that abstracts observations into models.The learned models provide a basis for the reasoning process, which might trigger actions affecting the system itself and possibly its environment.The LRA-M loop is a model-based formulation of the ODA loop.

FIGURE 2.
The reference architecture for self-managed systems from [74].
Another related architecture is the Reference Architecture for Self-managed Systems from Kramer and Magee [74]. Figure 2 shows this architecture which consists of three different layers with different tasks.The Goal management (the top layer of the architecture) is there for the planning.This is where plans are initiated to meet the requirements of the applications and to achieve their goals.Such plans may be required by new goals from the user or by requirements of the layer below.The Goal management layer usually has some awareness models to be able to reflect on the layer below and address it properly [51].This underlying layer contains Change management.This is where the various plans are stored, which shall be processed.The best plan for the respective current situation is selected in order to adapt the layer below.The Change management layer is also reflective and has typically an awareness model of the layer below; the lowest layer [51].This layer, the layer on the bottom of the architecture, is called Component control.Here, the actual functionalities of the application are implemented and accordingly adjusted by the instructions (based on various plans) from the layer above (Change management layer).The Component control layer is pre-reflective, and it sends up status reports to the layer above.If the Component control layer reports an inability to meet the given application goals, the Change management layer adapts it in a way it can achieve them in the current (environmental) situation [51].Besides the usage of various awareness models, the hierarchical structure of this approach matches the RoSA architecture IV-B2.
The Reference Architecture for Models@run.timeSystems is proposed in [75], and its main characteristic is that there is an explicit distinction between two systems often called managing system and managed system, where the first one manages the second one [51].The managed system can be divided again into the (actual) managed system and its environment.The managing system often has three layers accordingly to the above-mentioned Reference Architecture for Self-managed Systems, where the lowest layer has an interface to the managed system.While the top layer is very similar to the previous architecture, the bottom two layers are formulated much more precisely.The bottom layer contains configuration models (reflecting the current state of the managed system), plan models (controlling the managed system), capability models (covering the managed system's capabilities) and context models (focusing on the managed system's environment).The middle layer consists of a learner synchronizing all models of the lowest level with the managed system, a reasoner making decisions based on the models of the lowest level, and an analyzer abstracts the information provided by models of the base layer in order to enable a hierarchical decomposition.
The ''reference architecture for self-awareness'' from Lewis et al. [24] describes a psychology-inspired conceptual framework of self-awareness.The architecture defines a number of different units that can be used to describe a system with self-aware and self-expressive capabilities.The components are sensor and actuator units, self-expression unit, self-awareness unit, and meta-self-awareness unit.The meta-self-awareness unit assesses the desirability of maintaining a level of awareness.The self-awareness unit consists of several subsystems for certain types of awareness: • stimulus awareness is the knowledge about stimuli that act on the system and the ability to respond to them; • interaction awareness is the knowledge about the interaction between the system and its environment; • time awareness is the knowledge about past states and future phenomena; • goal awareness is the knowledge about objectives, preferences, and constraints as well as the ability to reason about them or manipulate them; • meta-self-awareness is the knowledge about possible levels of awareness and the way they are executed.
The recommended use of the reference architecture is described in a handbook [22].A case study about implementing a service selection application in the reference architecture is available in [24].Besides these reference architectures, a suitable modeling method, which is similar to our work, is proposed in [76].However, that model uses a vague definition of agents as design abstraction, while RoSA provides facilities for the definition of agents based on self-aware functionalities.

D. FRAMEWORKS FOR SELF-AWARENESS
There are frameworks that focus on particular self-* properties.SAPERE [77] and ACOSO [78] are middlewares that support self-organization of autonomic nodes in distributed environments.Though they build on an agent-based model like RoSA, they are focused on self-organization (a self-awareness property that is not covered in RoSA yet) and so provide complementary features to the current set of self-aware functionalities of RoSA.The following examples provide complementary features as well.BIONETS [79] is based on similar concepts and supports self-adaptation of autonomic nodes in distributed environments.The Collective Adaptive Systems approach of the ALLOW Ensembles project [80] supports collaborative self-adaptation of agents within groups called ensembles.SEEC [61] is a framework for self-aware resource allocation based on the concept of application heartbeats, which allows monitoring and adjusting program performance.We did not base our work on any of these frameworks because (i) SAPERE and ACOSO are implemented on top of JADE, which does not fit most ESs (Section III-F); (ii) the BIONETS concepts are implemented only in simulation models, which limits its deployability in real systems; (iii) the ALLOW Ensembles approach is demonstrated by a case study in DeMOCAS [81], which is a simulation framework implemented in Java and hence has limited deployability; and (iv) the implementation of SEEC does not match the agent-based architecture, which we selected for flexibility and scalability (Section III-F).
Although these works offer more or less specific design proposals for various self-aware systems, they do not constitute a complete modeling framework.

E. DECENTRALIZED ARCHITECTURES
Decentralized architectures have already been proposed in the early days of Artificial Intelligence (AI) [51].A decentralized system in this context consists of several agents (independent modules) which may interact with each other and work in parallel on their different tasks.According to [82], designing and building rational agents is fundamental for AI.Russell et al. further state that agents are rational entities that take the best possible action according to the information and capabilities they have at their disposal [82].
In [83], Wooldridge et al. define agents as software pieces that are autonomous (can autonomously operate without human intervention), social (can communicate with other agents or humans), reactive (can respond to changes in the environment), and pro-active (can take the initiative instead of just reacting).A Multi-agent System (MAS), in further consequence, is a system consisting of multiple agents that work together to fulfill one or more common goals [45].
An agent-based architecture (e.g., a MAS) implements the actor model [84], which is a programming paradigm known for scalable parallel and distributed computing.To better handle complex applications, it is usually advantageous to divide them into different tasks.Often these can be divided into different levels to cover the big picture as well as small details in particular.Accordingly, it can be helpful to have the possibility of a hierarchical structure.This is similar to the nature-inspired hierarchical system of the AC initiative from IBM [85].Applying a hierarchical agent-based approach to self-aware systems has been studied in the literature [86].An agent-based framework that facilitates self-awareness, however, has been an open issue.

F. AGENT-BASED FRAMEWORKS
Some existing self-aware frameworks are built on agents (see Section III-D).There are general agent-based frameworks, which are ignorant of the internal workings of agents.These are summarized in Table 1 and discussed in this section.
The two main use cases of the agent-based frameworks are multi-agent simulation and deployable actor system.Java-based frameworks have a high resource requirement beyond the typical capacity of ESs.The large-scale multi-agent simulation systems are not suitable for ESs for similar reasons, and they have limited capabilities for interfacing real hardware.Deployable actor systems with native implementation (Mobile-C and CAF) can support execution on ES hardware and are detailed as follows.Mobile-C is a small-footprint distributed actor system.However, it has a proprietary dependency and a custom native API, which limits its applicability.
CAF is an open-source distributed actor system with standard C++ implementation and with the aim of working on a wide spectrum of hardware platforms.Its extensive non-configurable feature set, however, makes it less suitable for ESs.A stripped-down version for resource-constrained systems remains a promise to date.

IV. THE RoSA FRAMEWORK
RoSA combines the agent-based actor model with self-aware properties in an ES-compatible fashion and is fully opensource.In this section, we discuss the general facilities of the RoSA framework, which are the agent-based architecture and details of its implementation.Actual functionalities are presented in Section VI, and the implementation of self-aware applications is showcased in Section VII by case studies.

A. TERMINOLOGY
Here, we define the following terms with the meaning we use in the context of RoSA and the rest of this paper.
1) Agents are design abstractions that help decompose a system into independent components.A classic definition of agents comes from the field of artificial intelligence [82]: ''an agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators.''RoSA agents comply with that definition.Section IV-B describes their inner workings and interactions.2) Data manipulation is the processing activity that is done by any agent: observing its environment via input, maintaining its internal state, and optionally generating output to affect its environment.Individual RoSA agents may realize different ways of data manipulation, which is described in terms of functionalities.3) Functionalities encapsulate self-awareness concepts in reusable components.They are the basic tools that can be put together to realize desired ways of data manipulation in agents.An agent is designed by a careful selection of functionalities for the required data manipulation.The self-aware functionalities that we have already implemented are elaborated in Section VI.

B. RoSA ARCHITECTURE
The architecture of the RoSA framework is outlined in this subsection, accompanied with a discussion on some design decisions.

1) SCOPE
The RoSA architecture supports modeling self-aware applications, whose relevance is motivated in Section I and Section II.The framework is intended to be a tool for modeling and evaluating novel ideas in self-aware applications.
The application model (i.e., a hierarchical agent-based system with functionalities within agents) is flexible enough to incorporate variations in different aspects of design and implementation.Those aspects are mostly related to the functionalities: (i) what functionalities are there, (ii) how they are implemented and interconnected, and (iii) how applications are decomposed.The architecture provides a structured and modular way for defining self-aware applications: applications are decomposed into agents, which are defined by functionalities.Agents and functionalities are reusable components in RoSA.

2) HIERARCHICAL AGENT-BASED MODEL
An agent communicates with its environment (i.e., other agents of the application) by message passing via input and output channels.Semantics can be informally given as: the agent receives messages on its input channels; manipulates data (i.e., the received messages and its internal state), and may send messages on its output channels.
Agents are organized into a hierarchical structure (e.g., Figure 3).Agents on different levels of the hierarchy process data on different levels of abstraction: the system obtains fine-and coarse-grained knowledge according to hierarchy levels.Such a detailed representation of knowledge helps self-adaptive systems to operate more efficiently and meet their goals [32].
Connected agents are in a master-slave relation.An agent (e.g., Agent 2 in Figure 3) receives messages from its slaves (Agents 5 and 6) and sends messages to its master (Agent 1).That is, an agent acts as slave towards its only master and as master towards its potentially multiple slaves.A slave sends messages to its master regularly according to its configuration.A master may control the configuration of its slaves by sending control messages to them whenever appropriate.
A real-world application interacts with its environment via sensors and actuators, which are modeled as agents in RoSA.An agent that wraps a sensor is a data source (i.e., has no slaves) and sends sensor input to its master.Dually, an agent that wraps an actuator is a data sink (i.e., has no master).An actuator is activated (''controlled'') by slaveto-master data messages -rather than master-to-slave control messages.

3) OBSERVE-DECIDE-ACT LOOPS
AC systems consist of autonomic elements implementing a control loop [36].Thus, self-aware applications in RoSA operate in an iterative manner implementing ODA loops [52].ODA is our architecture of choice, however, other architectures could be chosen and implemented as well.An ODA loop (Figure 4) represents the way reactive systems operate: the system monitors the behavior of itself and/or its environment, decides about certain actions, and acts accordingly.As shown in Figure 5, each RoSA agent operates in an ODA loop: receives input messages, does data manipulation, and optionally sends output messages.The composition of individual ODA loops results in a behavior that can be described as a compound ODA loop on the application level.The RoSA architecture provides a way to implement ODA-loop-based applications that are decomposed into interacting ODA loops of lower complexity.

4) FUNCTIONALITIES
An agent is defined by functionalities (Figure 6).What functionalities an agent utilizes depends on its role in the application.RoSA provides a library of pre-defined functionalities (Section VI) and allows developers to implement new ones either based on existing ones or from scratch.
As shown earlier, RoSA agents conceptually operate in ODA loops.The functionalities that constitute an agent contribute to different characteristics of observation and decision making in the loop.For example, abstraction (Section VI-A) improves the outcome of observation, and data reliability (Section VI-B) helps decision making by providing metainformation.Our approach is inspired by the hierarchical agent-based model of Guang et al. [76].While their model uses a vague definition of agents as design abstraction, RoSA agents are described as ODA loops that are based on functionalities.

C. SOFTWARE IMPLEMENTATION
We have implemented the RoSA architecture as a software framework.RoSA has a fully open implementation in standard C++ and can readily interface existing native software components.The main characteristics of the software implementation are (i) providing a high-level but safe modeling interface for application developers, (ii) allowing the same application code to be used for simulation and deployment, and (iii) realizing small-footprint software that can be deployed in resource-constrained ESs.We have done our case studies (Section VII) in simulation on a desktop computer.That is, input and output of sensor and actuator agents are fed to the system via stored files, and RoSA allows for other input-output interfaces as well.Runtime support for deploying on embedded devices requires further development to complete.

V. USE CASES OF THE FRAMEWORK
The section discusses how RoSA, the framework as a whole and its features separately, can be used in different scenarios.

A. MODELING A NEW APPLICATION IN RoSA
Modeling an application using the RoSA Architecture follows a general flow shown in Figure 7.That is, Specify requirements: The most abstract description of an application defines input and output (sensors and actuators, respectively) and the data manipulation to be done.It can be seen as an extreme agent system with all sensors and actuators connected to the only agent that represents the entire application.

Model agent system:
The monolithic application-agent is decomposed into a set of agents organized in a hierarchy.
Agents enclose specific kinds of data manipulation and serve as a unit of reusability -within and between applications.Identifying agent patterns can help efficient decomposition.Model agents: Each agent is modeled, i.e., prescribed data manipulation is realized by available functionalities and custom code (Figure 8).Functionalities provide a level of reusability below agents.RoSA provides a set of functionalities, which is expected to grow over time.Validate agents in simulation: Unit testing of agents is done by validating their input-output behavior in simulation mode: a single-agent system is evaluated with predefined input and expected output.Validate application in simulation: Agents are put together according to the system model.Integration testing of the application is done by validating the input-output behavior of the system in simulation mode.Deploy application: The application is deployed in an embedded device.
Though the RoSA methodology is presented as a sequential flow, the model of an application (i.e., the system model with corresponding agent models) may be refined in an iterative manner.

B. MIGRATING AN APPLICATION TO RoSA
RoSA can also be used to add self-awareness to existing applications.An entire legacy application can be migrated to RoSA in a few steps shown in Figure 7(b).That is, Wrap legacy components into agents: Each component, whose input-output behavior fits message-passing semantics, is wrapped into a RoSA agent.Legacy components may be grouped, if necessary.Existing legacy code implements data manipulation within agents.Build application from agents: Agents are put together in an agent system according to the connections between corresponding components in the legacy system.Refine model: The system and agent models may be refined iteratively, as in the general case.Deploy application: The agent system is deployed as a RoSA application.
This approach turns a legacy system into a RoSA application and enables utilizing all RoSA features for further development.

C. ADDING RoSA AS A SELF-AWARE COMPONENT
It is also possible to add a RoSA agent system to an existing application as a self-aware component (Figure 7(c)).This scenario might be applied as a gradual migration path.Identify self-aware component: The requirements are specified either as a new component of the application or based on an existing component to be replaced.

Realize component in RoSA:
The component is realized as a RoSA agent system following the general RoSA methodology (Figure 7).

Integrate component into the application:
The component is integrated into the existing application via input and output streams that are associated with its sensor and actuator agents, respectively.Deploy application: The application is deployed with the RoSA system as one of its components.
This approach limits the development effort to one component of the application -in contrast to migrating the whole application.However, additional development and runtime complexity is posed by the need to integrate RoSA as a component of the existing application.Whether to take the full migration or the component approach depends on the size of the application and how much the application needs self-awareness and can benefit from RoSA.

D. USING SELF-AWARE FUNCTIONALITIES FROM RoSA
RoSA supports reusability on two levels: agents in the system model and functionalities in the agent model.The realizations of these two levels are independent, and functionalities may be used without using agents.Should working with a RoSA agent system be uneconomic, functionalities that are defined in RoSA (Section VI) may be used in custom codes directly -without involving other parts of the RoSA framework.

E. IMPLEMENTING A GENERAL AGENT-BASED APPLICATION WITH RoSA
While the main aim of RoSA is to facilitate developing applications and concepts related to self-awareness, the applicability of the framework is not limited to that.The agent system that constitutes the base of the architecture can be used for any other application that may benefit from such an architecture (e.g., component-based systems).One can ignore self-aware functionalities and implement an agent-based application with all data processing in agents defined by custom application-specific code only.

VI. SELF-AWARE FUNCTIONALITIES
Each RoSA agent receives messages from its input channels and may send messages on its output channels.The data processing that the agent does to maintain its state based on input messages and generate output messages can be defined with full flexibility (i.e., custom application code).Nevertheless, RoSA provides predefined functionalities to be used as components when defining agents, with minimal glue code that connects them.It is also possible to mix functionalities and custom code freely within agents.The modularity enables application developers to define self-aware agents fast and efficiently by reusing existing functionalities and also customize data processing whenever needed.
The functionalities are based on self-aware properties [94], [95].RoSA provides reference implementations of the functionalities that have been used in our case studies (Section VII): abstraction, data reliability, confidence, and history.We expect the set of self-aware properties and corresponding functionalities to grow as well as their implementation to improve -contributions from the community are welcome.

A. ABSTRACTION
Abstraction is ''an appropriate selection of the representation of the information in order to obtain compact knowledge relevant to a particular purpose'' [94].It is a transformation of data from one domain to another.Raw input data may be abstracted into a semantic domain that the self-aware system understands [52], and the abstraction may be done at any level of a hierarchical system.It could also be done top-down instead of bottom-up [94].An abstraction needs to be meaningful and efficient in the system's context and to have a well-defined structure.

1) ABSTRACTION FUNCTIONALITIES AVAILABLE IN ROSA
The broad definition of abstraction allows for a wide variety of approaches.RoSA currently provides the following abstraction functionalities: 1) Lookup table maps an input datum to a symbol (e.g., number, character, string).2) Overlapping lookup table maps an input datum to potentially multiple symbols; in case the boundaries between symbols cannot be clearly defined (e.g., insufficient knowledge about the environment).Selecting one symbol in a later processing step may be a confidence-based decision (Section VI-C).In contrast, a standard lookup table maps an input value directly to one symbol.3) Threshold-based signal state detector abstracts steady states from a signal waveform, that is a sequence of input values.In other words, it recognizes stable phases in a signal.These steady states of a signal are identified concerning a threshold of distance among the signal's sample values.A signal state is stored as an average value of all input samples belonging to it.A simple learning algorithm is utilized internally for state detection.Detailed discussion is available in [29], [30].4) Confidence-based signal state detector also abstracts steady states from a signal waveform, that is a sequence of input values.These steady states of an input signal are identified concerning the relative distance among the signal's sample values.That is, in contrast to the Threshold-based signal state detector, the Confidence-based signal state detector makes all decisions based on a confidence assessment (Section VI-C).This assessment is not only based on a simple average, but on the most recent signal samples stored in a sliding window history.A detailed discussion of the learning algorithm behind this functionality is available in [31].5) System state detector abstracts a system state from signals of an observed system.The current implementation works with stateless systems only (i.e., identifying states of a system whose output can be expressed as a function of its input).

B. DATA RELIABILITY
Data reliability is ''the extent to which a measuring procedure yields the same results on repeated trials'' [94].The trustworthiness of data is determined by accuracy, precision, and truthfulness.The accuracy and precision are given by systematic and random error of measurement, respectively.Data can be accurate and precise but still not truthful [28], for instance, if a sensor is working outside of its operating conditions (e.g., a temperature sensor detached from the test object).Data reliability is a piece of meta-data about the trustworthiness of the input data stream.Further actions may be taken according to the reliability of data.The following measures may be used to assess trustworthiness: 1) Plausibility tells whether data is within its expected domain (i.e., range).If a variable exceeds the realistic limits of its represented quantity (e.g., human body temperature over 100 • C), data might be unreliable.2) Consistency tells whether data varies according to its expected variability (i.e., maximum difference between samples).If a variable changes too fast (e.g., position of a robotic arm), data might be not reliable.Checking consistency requires historical information (Section VI-D) about the input signal.3) Cross-validity tells whether one piece of data correlates with other pieces as expected.If two dependent variables (e.g., two interdependent vital signs) do not follow each other, data might be not reliable.

1) DATA RELIABILITY FUNCTIONALITIES AVAILABLE IN ROSA
RoSA provides functionalities for assessing each of these three measures of trustworthiness either in a binary or in a fuzzy way (a total of 6 variants).Binary assessment makes a binary decision about reliability according to a threshold.
Fuzzy assessment determines the level of data reliability in the [0, 1] range and can be configured with a custom function.
The individual assessments may be combined (e.g., considering both plausibility and consistency of a variable at the same time).RoSA provides a set of predefined methods (average and multiplication of fuzzy assessments; conjunction and disjunction for both binary and fuzzy assessments) for the combination, which may be done as custom application code as well.

C. CONFIDENCE
Confidence is ''the extent to which a procedure may yield the same results on repeated trials'' and has significant similarities to data reliability [94].Confidence is a piece of meta-data about the trustworthiness of the data processing performed by a (sub-)system or function.It tells how well a calculated result corresponds to the expected output.Assessing confidence assumes error-free input -which may be assessed by data reliability (Section VI-B).

1) CONFIDENCE FUNCTIONALITIES AVAILABLE IN ROSA
RoSA defines an interface for assessing confidence, but the actual assessment logic needs to be provided as a custom function.The lack of predefined assessment functions is because no general confidence measures have been identified yet.The assessment of confidence varies much on a caseby-case basis in our experience.
Besides this interface, RoSA offers a confidence-based abstraction method, which is an overlapping lookup table (Section VI-A).This method is based on fuzzy membership functions [96], and Figure 9 shows an example of it.The input data is mapped to three symbols (A, B, and C) so that two symbols are associated for the overlapping ranges (i.e., (A, B) and (B, C) for [p 1 , p 2 ] and [p 3 , p 4 ], respectively).The abstracted symbols are assigned with a confidence value according to their corresponding fuzzy membership functions (i.e., full confidence outside of the overlapping ranges and lower confidences inside them).The membership functions can be adjusted dynamically via control feedback in the agent hierarchy whenever a higher level agent recognizes a systematic error.
Cross-validity confidence tells whether one piece of data correlates with other pieces.It is similar to cross-validity reliability in that respect.However, it calculates historical correlation information based on active monitoring, unlike the a priori expectations of cross-validity reliability.This assessment can be used to tune confidence-based abstraction in lower levels of the hierarchy.
Individual confidence assessments may be combined, similar to combining individual reliability assessments.RoSA provides predefined combination methods and the possibility of handling combination by custom application code.The reliability of the output of an agent can be assessed by combining the reliability assessment of its input and the confidence assessment of its data processing.

D. HISTORY
History is ''recording and studying a series of past events connected to an entity'' and enables extracting knowledge from the recorded time series [94].Identifying trends in the past, understanding time-dependent aspects of the current state, and predicting future conditions [28] may all be supported by utilizing history.

1) HISTORY FUNCTIONALITIES AVAILABLE IN ROSA
RoSA includes limited support for history (only the features that we needed to implement other functionalities).A short description is still included because the history functionality can be used in the application code directly.
History functionality enables storing a sequence of data values.Its capacity can be configured for a balanced memory usage.History supports two strategies for redeeming memory once its capacity is reached: (i) stop strategy, when a full history does not accept further data values, and (ii) FIFO strategy, when history behaves like a sliding window.History functionality allows access to the individual stored values and also provides statistical properties (e.g., average) about the stored sequence.

VII. CASE STUDIES
Applications with different levels of self-awareness have been implemented in RoSA.We present two case studies in this section, which demonstrates how RoSA can be used for quick application development.

A. SELF-AWARE EARLY WARNING SCORE SYSTEM
The first case study is presented in detail for a smooth introduction of implementation details.The application -whose different variants are developed over the case study -is a health status assessment system.

1) BACKGROUND AND PROBLEM STATEMENT
Here, both, the calculation of the Early Warning Score (EWS) and the traditional EWS system are briefly described, before the next subsections deal with its extensions with various self-awareness properties.
A patient's health status can be assessed based on their vital signs.Research on cardiac arrests shows that certain symptoms can be observed long before the situation turns into a case of emergency; symptoms may appear even 24 hours before actual health deterioration [97].EWS is a standard manual tool for assessing patients' health status and predicting health deterioration.Healthcare professionals periodically monitor patients' vital signs (heart rate, respiratory rate, body temperature, blood pressure, and blood's oxygen saturation) and assess their health status by a criticality level defined as EWS [98].For this reason, each vital value is assessed in the form of a score.A score of 0 indicates an ideal health condition of a vital sign, while score 3 corresponds to the worst.The EWS is the aggregate value of all the individual vital sign scores.The higher the score, the higher the criticality.
This manual procedure has been applied to hospitalized patients.A portable device that automates the procedure would allow high-risk patients to pursue their daily lives with a much higher chance of survival.Robustness and fault tolerance is of major importance for such a device.Autonomous monitoring of patients in a non-hospital environment needs to deal with faulty measurements: sensors can be attached incorrectly, become detached, or break down.Incorrect measurements result in incorrect EWS, which might lead to false positive or -even worse -false negative assessments.
We developed several self-aware variants of the EWS application, which are able to deal with different kinds of faults [26]- [28].Those variants and their results are discussed in detail in the referred papers.Here we motivate their high-level design and present their implementation in RoSA.

2) THE CONVENTIONAL EWS SYSTEM
For starters, we implement an application that calculates the EWS in the conventional way (Figure 10).Five agents constitute the low level of the hierarchy, each connected to a sensor (modeled as a special agent) and assessing the corresponding vital sign.One agent in the higher level is connected to the low-level agents to make the aggregate assessment, whose result is recorded by a monitoring agent.The actual implementation is outlined in Listing 1.Even though RoSA and the applications are implemented in C++, the included listings use a C++-based pseudo-code for brevity.The sometimes verbose syntax of C++ is hidden, but the complexity of the application code is presented truly.
The implementation (Listing 1) starts with creating a RoSA Application (Line 1).Agents can be created and managed in the context of the Application.
For each vital sign (demonstrated by heart rate), a sensor (Line 2) and a low-level agent (Lines 4 to 21) are created.The low-level agent (Figure 10(b)) performs the EWS assessment by applying a lookup table abstraction (Section VI-A).The connection between the sensor and the low-level agent is established in a separate step (Line 23).
The high-level agent ((Figure 10(c)) aggregates vital sign assessments by summing them into a final EWS (Lines 26 to 31).Each low-level agent is connected to the high-level agent (Line 33).
The final EWS is logged to the console by a dedicated agent (Lines 36 to 40), which is connected to the high-level EWS agent (Line 42).

3) A SELF-AWARE EWS SYSTEM WITH RELIABILITY FUNCTIONALITIES
The conventional EWS system does not tolerate faults.Thus we make the system more robust by utilizing additional 1.RoSA implementation of a conventional EWS system.
self-aware functionalities within the agents (Figure 11).The agent hierarchy remains unchanged (Figure 10).Setting up the RoSA application and agent hierarchy is done similarly to the conventional EWS system (Listing 1).
The low-level agents (Figure 11(a)) assess the reliability of the abstracted vital signs by checking plausibility and consistency in combination (Section VI-B).The agent implementation is adapted by specifying the output as a pair of values (i.e., abstracted value and reliability assessment) rather than a single value and by utilizing reliability functionality in data processing (Listing 2 Lines 3 to 7).
The high-level agent (Figure 11(b)) assesses cross-validity reliability ((Section VI-B)) of the vital signs and combines all reliability assessments for the final EWS.The agent implementation is adapted similarly to low-level agents (i.e., adjust input and output types and utilize reliability functionality).
The reliability functionalities may be configured in different ways for the agents.Experiments have been performed both with binary [26] and with fuzzy [27] assessments.
Consider an experiment with the chest strap, which measures heartbeat, being loosely fastened.The measurement is not stable and provides unreliable readings during some time (e.g., 350s -670s in Figure 12), while other sensors provide reliable data.Though the EWS is calculated according to the standard rules (i.e., results in false positives), the assessed reliability drops to 0 during measurement errors.The low reliability indicates an issue with the system's input(s).

4) A SELF-AWARE EWS SYSTEM WITH CONFIDENCE FUNCTIONALITY
While the previous version calculated the EWS without any modifications, the final version adjusts the EWS in case of a low reliability [28].
The master agent (Figure 13(b)) additionally assesses cross-validity confidence of the vital signs (Section VI-C).The confidence assessment is based on personalized data and is -combined with the cross-validity reliabilityused as control feedback for the low-level agents to adjust their score abstraction process.The implementation, using predefined functionalities, is still only a few lines (Listing 3).The agent generates its output as (i) a pair of calculated EWS and assessed reliability (Line 6) and (ii) a list of confidence feedback for each low-level agent (Line 8).
Low-level agents (Figure 13(a)) perform confidence-based abstraction (Section VI-C and Figure 14), which takes historical information into account (Section VI-D) about feedback from the high-level EWS agent.The calculated EWS is FIGURE Agent descriptions in the EWS system equipped with reliability, confidence, and history.adjusted in that way.The actual implementation (Listing 2) is divided into two functions: (i) one for processing input, like before, and (ii) one for processing control feedback.Sensory input is processed like before (Lines 3 to 7) except for abstraction being configured to operate based on confidence (Section VI-C).Processing control feedback (Lines 11 to 14) passes data from the high-level agent to the local confidence-based abstraction.The feedback is stored by the abstraction functionality internally with a history functionality and is utilized when processing future sensory input.
Consider an experiment when participants are monitored with both working and faulty sensors (upper and lower part of Figure 15(a), respectively).The experiment results (Figure 15(b)) show that our self-aware EWS application performs much better (even if not perfectly) than the conventional system in the presence of sensory errors.The self-aware EWS system has almost 80 times less false alarms than the conventional system in our experiments [28].

5) SUMMARY
The detailed case study followed the development of our EWS application through four versions.That demonstrates that implementing an agent-based application with self-aware properties takes only a few steps in RoSA.Defining the agent system at the beginning was a lightweight task by using the existing agent interfaces of RoSA.Additionally, thanks to the modular design and reusable functionalities of RoSA, moving from one version to the next (i.e., including more sophisticated self-aware properties) needed only local modifications of agents and functionality configurations.
We were, of course, experimenting with different implementation alternatives during development.In the end, however, we packed the various functional components of data processing into functionalities, which are reusable modules.New applications can use those functionalities while they might also need to implement novel data processing approaches in custom application code.Those pieces of custom code, once matured, should be turned into functionalities for modularity and reusability.That is a way for sustainable development in the long run, and it is facilitated by RoSA.

B. CONTEXT-AWARE CONDITION MONITORING
This case study presents a monitoring system that assesses the working state and the health condition of another system or device; hereafter System under Observation (SuO).We limit the discussion to the modeling level (i.e., source-level implementation is ignored); the first case study provides insight into implementation.

1) BACKGROUND AND PROBLEM STATEMENT
Industry, particularly automated production plants, has an interest in reliable monitoring systems that are able to raise an alarm in case of malfunctions of the SuO [99].Such a monitoring and warning system enables optimization of maintenance work and minimizes downtimes.
Implementing tailor-made monitoring systems for each SuO is an expensive endeavor.A reliable self-adaptive monitoring system can reduce cost and time.We present such a system, which is able to assess the health status of any SuO without detailed a priori knowledge but by observing its input and output.The system assumes that the SuO meets two requirements: (i) the SuO works as a bijective function between its input and output, and (ii) the SuO operates in steady states.Requirement (i) allows the monitoring system to uniquely identify input-output pairs of normal operation.Dissociation of input and output signals is then considered a symptom of fault.Requirement (ii) is a consequence of the fact that the monitoring system discards unstable and transient signals.
The monitoring system adapts to any SuO based on contextual information only (see context-awareness).We have performed experiments with two variants of the system: (i) Context-aware Health Monitoring (CAH) [29], [30] applies a threshold-based decision-making process and (ii) Confidence-based Context-Aware condition Monitoring (CCAM) [31] makes decisions based on confidence.
Compared to similar monitoring solutions (e.g., deep learning and data mining), our system has a considerably smaller runtime footprint and can be applied to resource-constrained applications.

2) MODELING THE MONITORING SYSTEM
The application has a hierarchical structure (Figure 16).The low-level agents are connected to the sensors and can perform pre-processing of sensory input if necessary as well as incorporate a signal state detector (Section VI-A).
The detected signal states are combined into a system state by a system state detector (Section VI-A) in the high-level agent.Its output (i.e., system state and health condition) is processed (e.g., logging or trigging a warning in case of malfunction) by a dedicated agent.The signal and system state detector functionalities keep historical information about their input to identify steady states as well as recognize state changes and drifting signals (see [29]- [31]).Each new signal sample is compared with historical information to detect if the signal changed state.The historical information consists of an average value in CAH and a sliding window history in CCAM.If the new sample is in close proximity to the saved data of a recorded state, it belongs to that state.Whether a signal is stable or drifting is extracted from the course of the historical data.The state of the system is then the composition of the individual signal states.For further details, we refer to our corresponding works.
The state and health condition of the observed signal/system are outputs of the functionalities.The difference between CAH and CCAM is in the configuration of signal and system state detection: they make binary threshold-based and confidence-based decisions, respectively.CCAM provides better results than CAH.
Adjusting CAH/CCAM for a different SuO takes only two simple steps: (i) defining a low-level agent with a signal state detector for each input and output signal of the SuO and (ii) connecting each low-level agent to the high-level one and associating each signal to the system state detector either as input signal or output signal.The system is easily scalable, but the system state detector could become a bottleneck in case of an extremely high number of signals.This potential scalability issue is not caused by RoSA but by the architecture of the implemented application.In the case of such a complex SuO with a massive number of signals, the problem could be scaled out by replacing the central system state detector with a corresponding hierarchy of those.In other words, the SuO would be split up in various subsystems that have their own system state detectors, which may be combined in a hierarchical structure.This approach shows the powerful implementation of RoSA and its self-aware functionalities.Furthermore, this approach would overcome not only the issue of a bottleneck but also enables highly systematic monitoring of the SuO.

3) SUMMARY
Context-aware detection of different signal and system states is now enabled in RoSA by corresponding functionalities.However, no state detector was implemented when we started to develop the application.In the experimental phase, we implemented state detection as custom code in combination with existing RoSA functionalities (abstraction, confidence, and history).Reusing functionalities in a modular way, facilitated our efforts to implement complex data processing for context-aware state detection.We turned the validated implementations of signal and system state detectors into functionalities, which can be reused and configured by application-specific rules.

VIII. DISCUSSION
Before concluding, we enumerate the lessons learned from developing RoSA and the open issues already identified.We organize the discussion in three themes: modeling self-awareness in Section VIII-A, the software implementation in Section VIII-B, and implementing on ES hardware in Section VIII-C.

A. MODELING SELF-AWARENESS
An important lesson was realizing how much applicationdependent self-aware functionalities are.While a selfawareness property has some fundamental characteristic, a corresponding functionality may be implemented in different ways.For example, while confidence is a measure of how trustworthy the work of a task, part of the system, or the entire system is (Section VI-C), it may be calculated in many different ways [100] (see for example [31], [55], [101]).What interface to use for a self-awareness property depends on the actual usage.Therefore, each functionality must have a sophisticated interface to support modularity.This allows using functionalities directly or in combination with other functionalities to express more complex concepts.Whenever a new concept that cannot be built from the existing functionalities is to be developed, devising a modular interface for the new functionality is challenging but essential for reusability.
While the interfaces of functionalities are instrumental for reusability, details of their internal implementations can affect performance significantly.We provide a set of functionalities in RoSA; however, there might be better-working implementations.Hence, users of RoSA are not discouraged from adjusting and optimizing the implementations to their specific end-use.The modular design makes it possible to experiment with alternative implementations at will.In addition, users are encouraged to develop other functionalities whenever they have new ideas or specific needs.
We realize there is room for improving the modeling capabilities of RoSA.One limiting factor is the small set of implemented self-aware functionalities.Our research effort in self-awareness properties and functionality implementations will continue.We foresee exciting challenges in the area TABLE 2. Static and dynamic characteristics of the case studies (Section VII) executed on different ES platforms with different ARM cores (Cortex-A7 and Cortex-A15 implement the 32-bit ARMv7-A architecture, Cortex-A53 implements the 64-bit ARMv8-A architecture) shows that each application can work in real-time on ES hardware; note that numbers of different applications are not to be compared as they implement independent algorithms.and hope for the community's contribution in tackling them together to make RoSA a powerful common framework.FIGURE 17. Ratio of non-comment codelines of RoSA-based application code (Application) and that of the RoSA framework itself (Framework) relative to the number of non-comment codelines of corresponding custom-written applications in our case studies.The base-line (actual number of codelines) for each application is indicated below the application names.

B. SOFTWARE IMPLEMENTATION
We made RoSA to accelerate and simplify research on self-awareness through a reusable software framework.Comparing the number of non-comment codelines (as an indicator of development effort) of our original custom-written applications and that of the RoSA-based implementation provides a quantitative measure of how much the development effort is simplified by using RoSA.This comparison for the presented case studies is shown in Figure 17, where the custom code of the corresponding application is the reference, meaning 100%.The RoSA-based Application sizes relative to the corresponding custom code show that RoSA-based implementations stay relatively small (3.46%-6.24%),independently from the size of the custom-written applications.
Those implementations are small because they depend on the framework.The RoSA Framework size relative to the custom applications (the 100% references) shows that the overhead posed by the framework reduces (from an overhead of 120.4% for EWS to −40.72% for CAH/CCAM) as the size of the application increases (from 5481 to 20378 lines of custom application code for EWS and CAH/CCAM, respectively).The negative framework overhead indicates that even a custom implementation might be sub-optimal in case of complex applications.The quality of maintained framework code improves over time, while that does not typically happen with custom implementations developed in one go.
Averaging the sizes of all cases, we observe that on average, a RoSA-based implementation consists of only 5.18% lines of code relative to the custom implementation.The framework code has on average 20.75% more codelines than a custom application.The framework is, however, to be implemented only once and reused any number of times.Implementing a framework pays off when used for several applications.Particularly, implementing the framework and the four presented case studies in RoSA needed in total only 29.01% of the total number of codelines of our four original custom-written applications together; in other words, in total we needed 70.99% less codelines for implementing all four applications with RoSA.These figures confirm our initial hypothesis: an appropriate framework reduces the modeling and development efforts in self-aware systems.
Lastly, we realize that the capabilities and usability of RoSA as a software framework can be enhanced.For example, a graphical interface could help non-programmers to interact with models.Studying typical model patterns on both the agent system and the agent levels could help application developers in making better designs and utilizing available features efficiently.

C. IMPLEMENTING ON EMBEDDED SYSTEM HARDWARE
RoSA is a standalone actor framework with an open-source standard native implementation, to which CAF is the most similar from the existing agent-based frameworks (discussed VOLUME 8, 2020 in Section III-F).For deploying RoSA in ESs, we limited the implemented features to the essentials for our case studies without limiting the generality of the agent system.The binary size of the RoSA libraries on a x86-64 linux machine is 300 kB, while that of the CAF core library (version 0.17.5) is 7248 kB.This significant (24 times) difference in favor of RoSA indicates that our framework is applicable to considerably smaller systems than CAF.
As a preliminary confirmation of this hypothesis (suitability for ESs), we ran our case studies on the ODROID XU4 [102] and Raspberry Pi 3 [103] systems.The former has an eight-core big.LITTLE [104] configuration with Cortex-A7 and Cortex-A15 cores and the latter has a quad-core configuration with Cortex-A53 cores.The applications posed a moderate memory footprint well below 4 MB, which fits typical ESs, and processed samples several times faster than required for real-time execution.In Table 2, we have summarized the characteristics of each application implemented on each platform, where the real-time requirements and actual average processing times can be found.It has to be noted that the real-time sampling period depends on the nature of the corresponding application and that the table is not meant to compare the different applications.We plan to extend the evaluation of our software implementation by performing further extensive and vigorous tests by deploying RoSA on other real ES hardware in the future.

IX. CONCLUSION
Self-awareness is a hot topic, but related research and development efforts are fragmented among different fields and communities.Self-aware systems are developed from scratch in many cases.Such method of development, on long term, is redundant, inefficient and uneconomic.A major reason behind this fragmentation is the lack of a common framework that would facilitate development, cooperation, and reuse of existing results.
In this paper, we presented RoSA, a framework that aims to help researchers and engineers to explore the novel design space of self-awareness.RoSA supports modeling of self-aware applications as agent systems and modeling of agents based on self-aware functionalities.We presented the design principles of the RoSA architecture as well as use cases of RoSA-based modeling for different scenarios.The description of self-aware functionalities offered by RoSA and detailed case studies about applications implemented in RoSA demonstrate the modeling power and applicability of the framework.
Using RoSA relieves application developers from taking care of handling agents and message passing.Predefined functionalities serve as reusable components for defining individual agents.Data processing within agents can be defined as an arbitrary combination of custom application code and existing functionalities.Application code can thus be limited to the important aspects: (i) data processing within agents and (ii) the agent hierarchy of the application.
We promote RoSA as a vehicle for researchers to study various concepts that are related to self-awareness and the relation among them; and also for engineers to prototype and evaluate self-aware features in their designs with ease.

FIGURE 5 .
FIGURE 5.An agent system based on individual Observe-Decide-Act loops.

FIGURE 6 .
FIGURE 6.The behavior of an agent is defined by self-aware functionalities.

FIGURE 7 .
FIGURE 7. Scenarios of using the RoSA framework.

FIGURE 8 .
FIGURE 8.An agent is modeled based on available functionalities and custom code; reusable pieces of custom code are gradually promoted to functionalities in a generalized form.

FIGURE 9 .
FIGURE 9.A confidence-based abstraction method to abstract data into one or more symbols with a corresponding confidence.

FIGURE 11 .LISTING 2 .
FIGURE 11.Agent descriptions for the EWS system with reliability assessment.

FIGURE 12 .LISTING 3 .
FIGURE 12.Results of an experiment in which the heartbeat sensor was not attached properly and therefore incorrect measurements were made.

FIGURE 14 .
FIGURE 14.A confidence-based abstraction method to abstract a vital sign in one of four different scores (0 to 1).

FIGURE 15 .
FIGURE 15.Results of an experiment when participants were monitored with both working and faulty sets of sensors.

FIGURE 16 .
FIGURE 16.Architecture of CAH/CCAM for monitoring an AC motor.