A model-based reference architecture for complex assistive systems and its application

There are several definitions of reference architecture in the existing body of literature. Bass et al. [12] provided a definition that is based on the concept of a reference model specified as “a division of functionality together with data flow between the pieces [...] a standard decomposition of a known problem into parts that cooperatively solve the problem.”. A reference architecture is then defined as “a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them”. We use the above definition while concretizing software elements as components and interfaces.

Nakagawa et al. [76] established a reference model for reference architectures (RAModel) defining the following sets of elements to be implemented by such architectures: (1) domain: the elements of the problem domain (concepts, constraints, quality attributes, etc.) reflected in the reference architecture; (2) application: the scope and the functional requirements of the applications to be built based on this architecture; (3) infrastructure: software elements that could be used to build applications based on the reference architecture; (4) crosscutting elements such as architectural decisions or rules that are spread across the other elements.

The existing body of literature also contains several definitions for the process of building reference architectures. We follow the ProSA-RA process by Nakagawa et al. [75] containing the steps of information source investigation, architectural analysis and synthesis, and architectural evaluation.

We align our proposed reference architecture with RAModel and ProSA-RA process as follows: (1) we define the domain concepts related to assistive systems and context-awareness (domain set) further in this section (information source investigation step); (2) we specify the requirements to the assistive systems (application set) in the next section (architectural analysis step); (3) we specify the implementation components, interfaces, and their connections (infrastructure set) in Sect. 4 (architectural synthesis step); (4) we do not consider crosscutting elements; (5) we validate our reference architecture in Sect. 5 (architectural evaluation step).

Model-based software engineering (MBSE) considers using models and model transformations as the fundamental elements of software development. Here we restrict ourselves to consider the class of such systems that use models at runtime (models@run.time [17]), which means that the models expressed in some structured format are loaded into the running instances of the applications within the system to drive their execution. Note that introducing such a restriction means that we are not going to address MBSE activities related to other phases of the software development lifecycle such as dealing with models at design or development time. Models at runtime approaches allow for change of these models during system execution. This property allows us to cope with the change of a system and context information captured as data. Moreover, it allows for dynamic adaption as systems can modify their behavior based on information provided by models.

Figure 1 shows a minimal set of components (a fragment of a reference architecture) for a system that handles models at runtime. In this, we follow Mayr et al. [63, 64] which introduced a set of common components (positioned as architectural patterns) for such systems. Relevant components include (a) a model storage that permanently stores the models, (b) a model handler that parses and interprets the models obtained from storage prior to using them to control system functions at runtime, (c) a modeling tool that allows the modeler to create and manage models using some visual notation and transfer them to the running system, (d) (optional) a data to model transformer, which derives models from data.

In practice, model-based systems that handle models at runtime would include even more components, e.g.,  Aßmann et al. [8] propose a more complex reference architecture for the systems that use models at runtime including an analyzer, reasoner, monitor, and concrete modeling languages, e.g., to express goals as data flow in the reasoner. They define a managed system to be monitored and controlled, whereas this could be a human, a system, or a cyber-physical system (CPS) for assistive systems.

Assistive systems widely use models at runtime to provide assistance, such systems can be positioned as model-based assistive systems. Bencomo, Götz, and Song [14] have identified types of models for assistive systems using models at runtime. This includes, e.g.,  structure models for the system constituents and their states, behavior models defining what the system can or will do based on its current state, or goal models used to identify a current state and if certain goals are fulfilled or not.

Models at runtime can be integrated into assistive systems in various ways. Szvetits and Zdun [93] provide a comprehensive overview of which models can be used during runtime and for which purposes. For assistive systems, we can distinguish between the main perspective one has for defining these models: Are they describing humans in the real world (which then reflect in functionality of a system), or are the models describing mainly the system and its properties. To give some examples: Clearly, what types of models are integrated during runtime have an influence on what specific components and subcomponents are needed. Thus, approaches using models at runtime might differ in their concrete implementation but can share common constructs (see Fig. 1).

Context-aware systems [27] use context to provide relevant information and/or services to the user. This relevancy depends on the user’s task. Such context-aware systems have to provide means to handle different kinds of context in relation to human tasks. Following [81], there exist four phases in a context life-cycle for context-aware systems:

Figure 2 represents the main components, which are needed to allow these phases. We consider a data and knowledge base as the main component for the storage of related data. Another option would be not to use a database but pass on the data between acquisition and modeling directly, pass on models and context data from the context modeling to the context reasoning component, and pass on the enriched context data to the context dissemination component. This context dissemination could deliver context information by allowing the context-aware service to query for relevant information or using a publish-subscribe mechanism.

Model-based assistive systems need to be context-aware, as changes in the context might lead to different support solutions in reasoning processes [2]. MBSE for context-aware systems needs approaches for context modeling [71] to include all relevant information in addition to human behavior. Such context information provides additional information used for support, e.g.,  in which room a person is, handicaps, or functionalities a device provides.

An assistive system is a software system that “(1) provides situational support for human behavior, (2) based on information from previously stored and real-time monitored structural context and behavior data, (3) at the time the person needs or asks for it” [45]. Situational support requires knowing the relevant current state of the person and its’ context. Providing good support requires some adaptability of the provided support to fit specific user needs. These user needs are either known by the system and previously stored [71] or the user has to interact with the system and provide this information. This interaction can also be used to tell the assistive system that support is needed. Providing support at the time the person needs it is more complex as it requires knowledge about when to support a person based on her or his behavior or context changes.

Assistive systems should not be confused with the term “assistive technologies” [43], which describes devices for people with disabilities, which can be physical devices as well as software or cyber-physical devices. They are provided to specific user groups with mental, physical, or age-related disabilities. In contrast, assistive systems provide support functionalities to any user who is interested in being assisted.

Figure 3 shows the generic reference architecture for such domain-independent assistive systems. In this picture, red arrows reflect the sequence of steps in a process of assisting the users by means of the system, black arrows indicate the direction of the data exchange between the components, and the steps themselves are indicated by the numbers in circles.

In the first step, the behavior is monitored (1) using sensors [58] and the context of assisted persons [71]. This behavior is then handled (2) in the main application of an assistive system. In particular, the main application stores (3) both behavior and data. The storage could be either a single database or a set of e.g.,  relational databases, time-series databases for sensor data, or triple stores for ontologies. In the next step, (4) the application searches for known behavior and data in the storage and transforms it into knowledge about possible assistive actions. This can involve reasoning mechanisms [2]. When a person asks for assistance, the application, based on the possessed knowledge, uses (5) multimodal support and smart digital assistance devices [24] to provide (6) step-by-step support.

We use the reference architectures from Figs. 1, 2 and 3 as fundamentals for defining requirements and a reference architecture for model-based context-aware assistive systems.

To derive the functional requirements, we start with the definition of assistive systems from [45], presented in the previous section. Based on the three parts of this definition (situational support part, structure/behavior context part, and on-time part), we could identify the first set of requirements (see Table 1). An assistive system should enable system-to-person communication (R1), e.g.,  by providing step-by-step information, managing stored context and behavior data (R2), monitoring the person and her context (R3), e.g.,  via sensors and sensor middleware, enabling the interactive person-to-system communication (R4) and detecting an assistive need (R5), e.g.,  by identifying disorienting behavior or context changes.

Based on the above definition of assistive systems, it becomes clear that such a system needs to be aware of its context and could be, thus, called a context-aware system. Following [27], there exist three important context-awareness activities: (1) presentation of information and services to a user, (2) automatic execution of a service and (3) tagging of context to information for later retrieval. These three aspects result in further requirements (see Table 2). Regarding these activities, an assistive system should provide ways to present information (R6), e.g.,  in a GUI, give acoustic support, by vibrations, present services (R7), e.g.,  to choose between different support modes, allows the automatic execution of services or on devices (R8), e.g.,  to open the blinds or switch off a device, and to handle the previous context used for later support (R9). As we consider context as a part of our data, the concrete technique of we are tagging context to information (activity 3) is not needed. However, an assistive system should be able to handle the previous context.

As stated in Sect. 2, there exist four phases of a context life-cycle for context-aware systems [81], which are reflected in several requirements (see Table 3): For (1) Context Acquisition, we have identified R3 to monitor the person and her context via sensors, sensor middleware, devices, and virtual sources, e.g.,  monitor if somebody clicks on a button. For (2) Context Modeling, we have identified the need to create new models (R10), to merge new context data with existing information (R11), and to handle runtime models (R12), e.g.,  by workflow-, process-, or own engines or interpreters. For (3) Context Reasoning, we have identified the need to reason about models and make predictions (R13) which includes context preprocessing, sensor data fusion, and context inference. For (4) Context Dissemination, we have identified the need for interfaces between components storing data and services using context information (R14), the automatic execution of some components or services (R8), and the ability to control actuators (R15).

Aßmann et al. [8] propose a reference architecture for systems using models at runtime. This is reflected in the following requirements (see Table 4): The base layer includes models of the managed system which requires the ability to create, read, update, and delete models (R16), to have facilities to store and load models (R17), and to transform data from the monitored system into models (R18). The configuration management layer includes a reasoner (R13) to create a reconfiguration plan, needs to analyze runtime models and compare them with existing goals (R19), and a learner who updates models (R16) based on context data, and learns models by analyzing reasoning plans (R20). The goal management layer requires the handling of goals (R21).

In the next step, we have taken the functional requirements and grouped them into logical entities. Together with our own knowledge of the engineering of assistive systems, we have defined a set of general components that are able to handle the needed functionality. Table 5 presents an overview of the different requirements in column one. Column two indicates where the requirement originated from (A for the assistive system in Sect. 2.4, C for context-awareness in Sect. 2.3, and M for models at runtime in Sect. 2.2). The next columns show from 1 to 16 in which component the requirement should be handled.

As we rely on multiple sources while deriving the requirements, some of the requirements are overlapping. In particular, R1 and R4 overlap with R6 and R7, R10 overlap with R16, and R12 overlap with R13 and R19. However, we do not consider this as a problem as they are treated individually when mapping them to components.

To improve this categorization, we have revised our initial mapping after (1) completing the detailed description of each component and (2) a basic implementation of the components for an example project. The changes are highlighted in red (deleted mapping) and green (added mapping) in Table 5.

Some of the proposed components are optional. Figure 5 provides an overview. Which components are used depends on the main properties of the assistive system. We have identified four different system properties, which influence which combination of components should be chosen: the way of data handling, the degree of support, the learning abilities of the assistive system, and the degree of customizability by users.

Learning assistive systems. Assistive systems might be operated with learning and support phases [92]. If they start with an explicit learning phase, the system learns by creating models from data, and a component that automatically transforms data into models (C5) is needed. However, models might also be created and added manually which would not stop the assistive system from including learning abilities, e.g., by comparison of sensed data with information in models which is done in C6, the reasoning of new knowledge in C7 based on existing knowledge, and updating or adding new models using the model administration component (C14).

We see two main areas of application for our reference architecture: analyzing existing architectures and using the reference architecture as a blueprint for creating a new architecture. Within this paper, we are focusing on the analysis of existing architectures. We use the following method: For each component of the architecture under consideration, we have investigated the existing implementation and identified to which component in the reference architecture it corresponds. These findings were mapped to the graphical representations of the system architecture. For a reflection on this method and its limitations, we refer the reader to Sect. 7.

Within the Human Behavior Monitoring and Support (HBMS) project [72], a group of researchers has developed an assistive system to support the elderly in their daily activities in their private homes.

System architecture. Figure 6 shows the main architecture of the developed system. This architecture is designed to make it possible for this system to learn the behavioral knowledge of the person when his/her cognitive abilities are intact and preserve this knowledge by means of domain-specific modeling language HCM-L [62], so it can be reused when these abilities begin to decline. The system provides support in problematic situations (e.g., when the person forgets the next steps or makes a wrong step in an activity of daily life) by suggesting the course of actions based on the previous behavior.

To express the architecture of HBMS in terms of compliance with our reference architecture, for each of its described components, we show the code of the corresponding component of the reference architecture in parentheses; in Fig. 6 they are shown within circles on top of the mapped HBMS components. For each of the described connections between components, we show the codes of the components at the ends of the connection in parenthesis and separate them with a dash: e.g.,  “(1)–(5)”.

The HBMS architecture consists of the following components: Compliance with the proposed reference architecture. Our main findings regarding the compliance of the HBMS architecture to our proposed reference architecture are as follows. Communication Compliance. We have checked each connection between the components in the reference architecture and their occurrence in the architecture within Fig. 6. First of all, as several optional components (C10, C12, C13) are not present, all connections referring to them and from them are not present as well. Similarly to missing optional components, this, in our opinion, does not disqualify HBMS from being compliant. On the other hand, some connections involving non-optional components, namely C1 to C5, C2 to C5, C4 to and from C8, C4 to and from C14, C6 to and from C7, C11 to C4 and C11 to C7, are not represented in the architecture directly. Still, most of these connections can be followed via other components of the system. For example, the connection between C4 (implemented by HBMS Data Management Subsystem) and C14 (implemented by the HBMS Modeling Tool) can be followed through C5 (implemented by HCM-L Model Transfer Interface) and C6 (HCM-L-OWL converter). The exception here is the connection from C1 to C5 which is missing from the HBMS architecture, as the HBMS Modeling Tool does not obtain the input from the Smart Home Environment. This indicates the possible way for the improvement of the architecture.

To sum it up, the analysis of the HBMS system has shown that all mandatory components and all except one mandatory connection defined in the proposed reference architecture occur directly in this system or can be followed through intermediate components. Thus, we conclude that the real-life HBMS system complies almost fully with the proposed reference architecture. This fact of compliance, together with the fact, that the perceived mapping inconsistencies helped to identify real design problems in the HBMS system, contribute toward the validation of the proposed architecture.

Dalibor et al. [26] use a Model-Driven Software Engineering (MDSE) approach to create digital twins and their cockpits. They define a digital twin as "a set of models of the system, a set of digital shadows and their aggregation and abstraction collected from a system, and a set of services that allow using the data and models purposefully with respect to the original system" [26]. Those software systems include models, data, and services to interact with a Cyber-Physical Production System (CPPS) for a specific purpose. Such digital twins might include assistive services to provide support for operators in production processes, e.g.,  on the shop floor.

System architecture. Figure 7 shows a reference architecture for such digital twins, which realizes the MAPE-K feedback loops [5] for self-adaptive systems. The researchers use a MDSE approach to generate the adaptive look from UML Class Diagrams (CDs) and MontiArc models [26] and the visualization backend and frontend from CDs and GUI models [37]. The architecture consists of the following components:

Compliance with the proposed reference architecture. This mapping has shown which components of the digital twin can be used to provide assistive functionalities within a digital twin of a CPPS. However, there are some aspects missing from the reference architecture to provide full support.Communication Compliance. We have checked each connection between the components in the reference architecture and their occurrence in the architecture within Fig. 7. As several components do not exist, all connections referring to them and from them do not exist. Moreover, the Data Distributor and Data Connector (C4) lacks several connections to other components, and several connections are not modeled directly but indirectly through other components, e.g., C8 to C9, C11 to C4, C5 to C4, or C2 to C4. This shows that the current approach stores less information that might be relevant for assistive systems and is more restrictive regarding which components interact. To add assistive functionalities within this architecture according to our reference architecture, several connections need to be added.

To sum up, the analysis of this system has shown that several of the components defined in Sect. 4 occur in this system. As it is now, it does not provide all the functionalities needed for an assistive system. However, it became clear what components and data flows are missing and need to be added to be able to provide assistance for operators.

Surveys of reference architectures for assistive systems not necessarily addressing using models at runtime are available in [29, 33]. Below we consider some specific works.

Liu et al. [56] presented a reference architecture of assistive hardware devices and services aiming at improving the quality of life of older people. Compared to our architecture, it is more hardware-oriented, provides fewer functions (no support for actuators, no reasoning mechanism, etc.), and does not explicitly include model-handling components (it, however, mentions dealing with “models, rules, and policies” without elaborating on that).

El Murabet et al. [30] proposed RAFAALS reference architecture for AAL systems as an architectural model based on the “platform as a service” (PaaS) principle. It uses BPMN models to drive the execution of services, though it does not provide means for creating or maintaining such models, also, it does not define interaction management components.

Oestreich et al. [78] proposed the adaptive workflow architecture for digital assistance systems (mostly aiming at supporting instructional systems, i.e., not limited to AAL). It is based on runtime BPMN models, including such components as Modeler, Editor, and Canvas to support the creation of such models, and Process Engine for their execution. The other component groups include Adaptive Assistance (with Companion component), Process Monitoring and Analytics (with Dashboard component), and Adaptation (including, besides Process Engine, the Adaptation Component and plugins). It does not include actuators, does not use any external knowledge, and is not explicitly positioned as a reference architecture.

Augusto et al. [10] proposed the system architecture for smart environments; their treatment of the system architecture can be adapted to provide a reference architecture for the specific domain. Most of its components are also defined by our architecture, still, it lacks an explicit treatment of model support or dealing with external knowledge.

Personal Connected Health Alliance (PCHA) published Continua Design Guidelines that provide a reference architecture (Continua End-to-End Reference Architecture) for interoperable healthcare ecosystems [100]. This architecture includes the concepts of Personal Health Device, Personal Health Gateway, Health, and Fitness Service, and Health Information Service, the communication between implementations of these concepts is performed by means of Personal Health Devices Interface, Service Interface, and HIS Interface. It introduces a set of models: Domain Information Model, Communication Model, and Service Model, but the correspondence between these models and the models@run.time paradigm is not shown.

ECHONET consortium proposed the ECHONET Lite reference architecture to support interoperability of home appliances [51]. It includes the concepts of Home Appliance, Home Gateway (connected by means of ECHONET Lite protocol), Cloud Server, and Application (connected by means of ECHONET Lite Web API). One of the implementations of this architecture is introduced in [74]. Pham et al. [82] described a concept that supports the interoperation of the implementations of both PCHA and ECHONET Lite reference architectures. As for PHCA, ECHONET Lite also does not rely on models@run.time; in particular, the above implementations do not provide any model handling or interaction support.

Garcés Rodríguez, Zanin Vicente and Nakagawa [34] present a software architecture for healthcare systems to assist patients with diabetes mellitus. This architecture is generalized in [85] as HomecARe: a reference architecture for chronic disease management at home. These architectures include additional services for, e.g.,  quality checks and describe various needed databases as information sources in detail. They also include a business process model for activities regarding the patient, though the model administration component is not described in detail. In addition, they lack details on the support devices, include no actuators or automatic execution, and are very specific to their application domain. Still, HomecARe includes the richest set of components among all architectures we reviewed, though the way of presenting it (as a connection-less overview diagram supplemented by a set of smaller-scope diagrams that describe component interaction) makes it difficult to check the communication compliance.

Among less recent reference architectures targeting AAL domain are Feelgood [44], MPOWER SOA [73], OpenAAL [101], and PERSONA [94]. Here, the richest set of components is provided by PERSONA, which, however, completely lacks support for administrative components and does not define actuators.

To sum it up, most of the above approaches, not targeting models@run.time directly, do not support model-related components (C5, C6, and C14) in full. Many of them, however, support dealing with models and rules partially, usually by mentioning that such structures can be used to drive the support, without discussing these issues in detail. The level of support for other kinds of components varies by solution, we can state that getting the data from sensors (C1 and C2) is supported much more widely than providing interaction support (C11) or dealing with actuators (C13).

Following Hu, Indulska, and Robinson [46], there are three main approaches to building context-aware applications: (1) without application-level context model, (2) with an implicit context model (3) with an explicit context model. The latter is the most relevant for our reference architecture. Roda et al. [84] provide a study on software architectures for context-aware systems. It is possible to implement their guidelines for modeling, retrieving, and managing context with our reference architecture. A specific reference architecture for context-aware systems is presented by Lewis et al. [55], the architectural components of such systems are also addressed in detail by the CASA architecture by Augusto et al. [11] and by a context-aware architecture for personal healthcare smart gateways by Santos et al. [88].

In addition to the more generic context-aware approaches listed above, the architectural approaches for context-aware Internet of Things (IoT) systems (reviewed by Perera et al. in [81] and represented by a context- and self-awareness architecture for the IoT by Arnaiz et al. [6]) and the approach to model and execute context-sensitive production processes by Alexopoulos et al. [3] would also fit into our proposed reference architecture.

Among the approaches to handle context-awareness, the reference architecture by Lewis et al., and, to lesser degree, the IoT architecture by Arnaiz et al. offer the richest set of components, coming closest to our approach. The problem with these and other approaches of this kind is that they lack assistive services for the supported human (not including, or partially including C9 and C11), and do not support actuators.

A broad variety of self-adaptive systems implement the MAPE-K feedback loop [5, 87]. Addressing four MAPE-K steps is a goal of a typical set of components that are found in assistive systems. In particular, Grua et al. [39] propose a reference architecture targeting the development of personalized and self-adaptive e-health apps for smartphone-centered environments which includes a specific set of components supporting self-adaptation by implementing MAPE-K loops (e.g., user-driven adaptation manager). The problem with such steps is that they typically do not focus on the human-in-the-loop to be assisted but on the automatic change and execution of changing goals.

Further specific examples of reference architectures targeting self-adaptive systems are RA4Self-CPS [79], a reference architecture for resilient behaviors control by Bemthuis et al. [13], HAFLoop [102], and self-adaptive digital twin reference architecture by Splettstosser et al. [91]. Among these approaches, RA4Self-CPS includes the richest set of components, coming close to our architecture; it, however, lacks external knowledge support and does not fully support interaction support or actuators, whereas self-adaptive digital twin architecture by Splettstosser et al. does not address human support at all (not implementing C9 and C11), and does not include administrative components, actuators, and external knowledge support. Finally, HaFLoop, being a reference architecture specifically targeting the support for adaptive feedback loops, is not supposed to be used to design standalone architectures, so it does not include any explicit support for sensors, storage, or administrative components.

From the comparison in Table 6, it can be seen that no existing architecture includes all the components proposed by our reference architecture. The reference architectures closest to our approach, such as HomecARe, PERSONA, the context-aware architecture by Lewis et al., or RA4Self-CPS, still lack the support of important components, such as actuators, explicit model handlers, or interaction support components. In our opinion, this further emphasizes the novelty of our approach.

We also observed that the supported subset of components depends on the type of the system: for example, context-aware systems put more effort into handling models (C5 and C6), whereas self-adaptive systems are more likely to implement support (C8) and interaction management (C11) components.

One further observation is related to the components which are mentioned the least. Among them, model and system administration (C14 and C15) are rarely presented as, in our opinion, academic solutions rarely reach a high technology readiness level and therefore do not consider aspects such as the long-term maintenance of systems. Service presentation (C10) is rarely mentioned explicitly, as, in our opinion, architecture authors often do not feel the need to separate it from the rest of the user interface, though its functionality may be still present. Also, the support for actuators (C13) is limited, which may diminish the quality of system-to-user interaction.

Our guidelines for analyzing and developing systems are based on the blueprint already presented in Sect. 4.2. In particular, for analyzing systems, we propose to establish a checklist (e.g.,  in a form of the Excel spreadsheet), which can be followed against the current system architecture. Such a checklist may include the list of components, together with the indication of components providing the input and output of each component (taken together, such input/output specifications actually define the relationships between components). While filling the checklist, the analyst may specify the name of the system component which implements the particular component of the reference architecture (if it exists), and the name of the component which serves as an input or output for the specific system component (again if it exists).

If deviations are detected in real-world scenarios, e.g., components or connections are missing, the development team can use the reference architecture to discuss (1) how the requirement related to a component is related to their concrete system requirements and (2) how adding each of the relationships from the reference architecture would influence the data flows within their implementation. Moreover, we suggest that the team evaluating the architecture includes developers who are very familiar with the implementation to make these discussions easier.

Resource Reduction and Development Effort. We have developed a case study for supporting the cooking process in a smart kitchen [69]. It took one student app. 4 months to come up with the first implementation of the whole assistive system. This included (a) setting up the system architecture, (b) the creation of two new Domain-Specific Languages (DSLs) to be handled as models at runtime, a task and a context modeling language, (c) a survey to get feedback on the design of the system, (d) creating models, pictures, audio support, and making hand-written additions to the partly generated system, and (e) performing an evaluation with end users to get additional feedback. Thus, we can state that the development effort was relatively low to realize such a system. The proposed reference architecture helped to reduce this effort as follows. (1) As the detailed descriptions of each system component, its in-, and output as well as the functionalities provided a more systematic way of structuring the code in the first place, this enabled the creation of a basic structure fast. (2) The described requirements were used as a starting point to further refine the requirements for the domain-specific application. (3) As some components are marked as optional and serve specific system properties (see Sect. 4.1), this helped the student to focus on the implementation of the most relevant components and connections for the particular application domain and its use cases. (4) In cases where it was unclear in which system component a certain functionality should be included or where specific data and models should be handled, the descriptions helped to make decisions faster. This is mainly because our reference architecture follows the separation-of-concerns principle and suggests a high cohesion within each component. (5) When extending the implementation, this separation of concerns helped to identify which components needed additional subcomponents to realize additional functionality. (6) When refactoring the code during the development process, again the functionality descriptions and comparing the actual input and output of components with the suggestions in the reference architecture helped to identify if certain implementation details should be moved to other components.

A quantitative comparison of the effort needed for an implementation without the reference architecture is, however, a common challenge we are facing in software engineering research: Developers have different skills and learn when doing the same task more than one time, the realized domains and software characteristics differ in size and complexity, and requirements change during implementation. Thus, we are currently applying the reference architecture to several applications and case studies to be able to quantify the development effort. However, as we are also using model-driven engineering approaches for the development of such systems, this could also have a strong influence on the development effort.

The presented reference architecture describes an assistive system on a higher level of abstraction. If one wants to further explore the benefits of reference architectures, such as the reuse of common functionalities and configurations in the generation of systems, reduced risk through the reuse of proven architectural elements, or better quality [61], one needs to break the reference architecture down to concrete domains and provide concrete reusable implementations for the components of the reference architecture.

Limitation of expressiveness. Defining systems on a component level using textual descriptions and analyzing them based only on their architectural models has only limited means to express if a component really provides what is needed for a specific assistive use case. For example, if we have an Information Presentation component in the architectural description, this does not ensure that there exists an acoustic way of information presentation for an operator in a noisy environment. Such aspects have to be further analyzed regarding the specific requirements from the domain.

Reference architecture validation vs. formal compliance checking. Clearly, how to represent reference architectures and how to check the compliance of reference architectures to concrete implementations are commonly known problems [19]. Approaches such as described by Bucaioni et al. [19] require component connector models of the reference architecture and the concrete implementations. They describe an approach combining model transformation and weaving techniques allowing for the automatic conformance checking of concrete architectures. This is based on various types of conformance, e.g., if an architecture conforms to constraints, rules, and characteristics of the reference architecture, the architecture language grammar, architectural styles, and additional constraints. These approaches have other goals in comparison with our approach: If the goal is to identify misalignment between reference and concrete architectures as one of the main causes of architectural technical debts or to define Software Product Lines (SPLs) where products must conform to the architecture of the related family, it is important to strictly follow a reference architecture. In more general, [52] suggests a more formal approach to define conformance between two models without explicitly referring to reference architectures. Following [52], a conformance relation is a binary, reflexive, transitive relation that describes whether the concrete model is a concretization of a reference model. In addition to this, concrete conformance rules need to be defined for each language, e.g., architecture description languages.

Deeper exploration of different kinds of runtime models. Systems that use different types of models at runtime might require additional subcomponents handling the specific model types within the Model Handler (C6). We have already explored how to use behavior models [2], task and context models [69] as well as goal models [70] within assistive systems. However, Szvetits and Zdun [93] list significantly more kinds of models existing for models at runtime approaches, e.g.,  observation models, feature models, aspect models, Abstract Syntax Trees (ASTs), or safety models. Thus, an exploration of these different kinds of modeling approaches could be an interesting research topic.

Requirements elicitation. As mentioned in Sect. 2.1, we followed the ProSA-RA process while designing our reference architecture. While following this process in general, and, in particular, conducting its requirements elicitation step, we did not elaborate on the requirements elicitation process in detail, limiting ourselves to obtaining requirements based on the domain-specific definitions found in the state-of-the-art literature. The reason is that such a process should rely on the generic standards for collecting requirements for the assistive systems which rely on using models at runtime, but we are not aware of all standards of every possible application domain in the necessary detail.

Vague requirements. The presence of vague requirements (to some extent) hinders the external validation and replication of the study. E.g., the requirement to create new models without mentioning which types of models these are, or to enable person-to-system interaction without mentioning how and with which technologies. In our opinion, this vagueness is inevitable, as some of the requirements must be kept general to allow for heterogeneous implementations in different application domains and with different technologies. They will become more concrete if a domain-specific implementation is considered based on the reference architecture and the requirements are further detailed with the specific end users of the assistance system. To mitigate this risk, we have added a comparison with components in existing reference architectures covering some of the proposed aspects in Sect. 6. However, this does not completely resolve this limitation.

Validating the architecture by asking the experts. While following the ProSA-RA process in most of its activities, we deviated from this process by omitting the use of the FERA checklist [89] for evaluating the resulting architecture as we found it overly detailed (consisting of 93 questions grouped into several categories) and too relying on the specific knowledge possessed by the experts. As our architecture is based on the knowledge belonging to multiple domains, we expect difficulties with recruiting unbiased experts which possess the knowledge belonging to all these domains. We also expect difficulties in persuading experts from practice to invest their time for the whole set of questions belonging to the checklist. Still, in future, we plan to organize the evaluation based on the modified version of the checklist taking into account these considerations.

Architectural styles, such as Client/Server, Microkernel, or Microservices are often defined as parts of specific reference architectures [76]. We, however, decided to make our architecture style-independent, as the fundamental property of the systems compliant with it is that they have to be based on runtime models, and enforcing this property does not depend on selecting a specific architectural style. As a result, we limit ourselves to checking component and communication compliance, where required components and their connections can be implemented by means of applying a specific architectural style.

To create the reference architecture, we have only considered functional requirements, since we treat non-functional requirements as application- and technology-specific. Those are addressed by deriving the specific implementation architecture of a domain-specific system from the compliant model-based architecture, and, in particular, by applying a specific architectural style, which we consider as outside the scope of our work.

Still, non-functional requirements as quality attributes significantly impact assistive systems. Thus, we describe their relationship with assistive systems and provide some examples.

Privacy. As assistive systems are human-centric systems [41, 47], they partially need the private information of their users. Using this information enables assistive systems to be adaptable to specific user needs. To support the privacy-aware handling of data, we can rely on privacy-by-design principles [21] in the engineering of assistive systems. Privacy cannot be centered within one specific component in the software architecture but is again a cross-cutting topic. We can introduce privacy checkpoints [59, 66, 68] within the software architecture in each point where data passes happen. E.g., from monitoring components (C1) to the data (pre)processor (C2), and from any component to and from the storage manager (C4) and the data and model storages (C3). Thus, such non-functional privacy requirements have more influence on the communication between components than the concrete components of the reference architecture. To further elaborate on this idea, further studies are needed considering different privacy checkpoints in a concrete assistive system architecture.

Maintainability. [61] report on reduced maintenance costs due to the use of reference architectures and [80] on improving the maintenance of software with the use of model-driven approaches. Having a clear reference architecture supports the separation of concerns by avoiding redundancy. However, non-functional maintainability requirements are again not explicitly reflected in a reference architecture.

To sum up, different kinds of non-functional requirements will be added to the list of requirements for a specific realization of an assistive system. These might translate to functional requirements, e.g., which encryption method to use, with which firewall or authentication system an assistive system has to be compatible, or how many servers are needed to be able to handle the workload. Thus, they have to be considered e.g.,  in the implementation architecture of a system.