A Model-Driven Engineering Process for Autonomic Sensor-Actuator Networks

Cyber-Physical Systems (CPS) are the next generation of embedded ICT systems designed to be aware of the physical environment by using sensor-actuator networks to provide users with a wide range of smart applications and services. Many of these smart applications are possible due to the incorporation of autonomic control loops that implement advanced processing and analysis of historical and real-time data measured by sensors; plan actions according to a set of goals or policies; and execute plans through actuators. The complexity of this kind of systems requires mechanisms that can assist the system's design and development. This paper presents a solution for assisting the design and development of CPS based on Model-Driven Development: MindCPS (doMaIN moDel for CPS) solution. MindCPS solution is based on a model that provides modelling primitives for explicitly specifying the autonomic behaviour of CPS and model transformations for automatically generating part of the CPS code. In addition to the automatic code generation, the MindCPS solution offers the possibility of rapidly configuring and developing the core behaviour of a CPS, even for nonsoftware engineers. The MindCPS solution has been put into practice to deploy a smart metering system in a demonstrator located at the Technical University of Madrid.


Introduction
Cyber-Physical Systems (CPS) refer to ICT systems (sensing, actuating, computing, and communication) embedded or software integrated in physical objects, interconnected, and providing citizens and businesses with a wide range of smart applications and services [1][2][3].Examples of these CPS include smart buildings, cities, energy grids, and water networks.These CPS are designed to monitor and respond to the physical environment, enabling fast, effective autonomic control loops between sensing and actuation, possibly with cognitive and learning capabilities [1].To sense and act upon the physical environment, CPS are often built on wireless sensor/actor networks (WSAN) [4].Autonomic control loops implement (i) information monitoring, (ii) advanced analysis and processing of historical and real-time data measured by sensors or other external sources, (iii) planning of actions according to a set of goals or policies, and (iv) execution of those plans through actuators.This implementation is supported by real-time or historical knowledge.CPS systems are complex due to factors such as the heterogeneity of sensors and actuators, the definition of complex conditions and patterns for problem detection over a large amount of data and events, the needs for real-time processing, and the implementation of plans for problem solving.This complexity makes engineers require mechanisms and tools that could assist them during the systems design and development.
This paper presents a solution for designing and developing CPS, specifically CPS that are conceptualized as a set of smart nodes distributed throughout a WSAN that implement autonomic control loops for smart sensing and actuation.This solution is a Model-Driven Development process (MDD [5]), called MindCPS (doMaIN moDel for CPS).MDD is a software development approach in which the focus and primary artefacts of development are models-as opposed to programs-and model transformations [5].The automated and semiautomated code generation through model transformations provide benefits in terms of increase of productivity, facilitated maintenance and portability thanks to the quality of the produced code [6,7].MindCPS provides modelling primitives for explicitly specifying the autonomic behaviour of CPS.Te MindCPS solution also includes the defnition of a set of model-to-code transformations for automatically generating the following: (i) Java code that implements the "core behaviour" of the smart nodes of a CPS (i.e., the autonomic control loop for smart sensing and actuation and communication through an event publish-subscribe middleware); (ii) the EPL (Event Processing Language) queries of an Esper CEP engine (Esper is a component for complex event processing (CEP) and event series analysis available for Java.) that implement the advanced analysis and processing of real-time events coming from monitored and fltered measurements of sensors; and (iii) the SQL queries of a database manager that implement the advanced analysis and processing of non-real-time data coming from monitored and fltered measurements of external sources, services, or even sensors without real-time restrictions.Te automatic code generation increases the productivity of constructing CPS thanks to the development time reduction with regard to the traditional programming (the hand-made development).Te advantage ofered by the MindCPS solution, in addition to the automatic code generation, is the possibility of rapidly confguring and developing the core behaviour of a CPS, even for nonsofware engineers, thanks to its graphical and intuitive domain language.Finally, it is important to emphasize that this solution has been iteratively designed by extracting the code generation patterns from our industrial experiences.Tese code generation patterns have been iteratively refned and enriched by each case study.Tis makes that most of the generated code had been previously tested in terms of functionality and performance.Tese industrial experiences together with the MindCPS solution are the result of research initiated in two larger ITEA2 projects, IMPONET (intelligent monitoring of power networks http://innovationenergy.org/imponet/) and NEMO&CODED (networked monitoring & control diagnostic for electrical distribution http://innovationenergy .org/nemocoded/).Tese projects focused on supporting complex and advanced requirements of smart grids [8], specifcally supporting enhanced efciency through sensing and metering technologies, as well as automated control and management techniques based on energy availability and the optimization of power demand.To illustrate the application of the MindCPS solution, we present the implementation of a demonstrator for smart metering following the MindCPS process.
Tis paper is structured as follows.Section 2 briefy introduces the concepts of CPS and WSAN, autonomic computing, and MDD.Section 3 presents the MindCPS solution for designing and developing autonomic smart nodes of CPS over a WSAN.Section 4 describes the use of this MDD process in a demonstrator for smart metering.Section 5 describes related work.Finally, conclusions and further work are described in Section 6. process information from the physical environment, ofen in real time.Tese CPS are then able to make decisions and act upon the physical world through actuators.In order to realize these sensing and acting capabilities, CPS are ofen built on WSAN [4].However, the deployment of complex sofware to perform these tasks in WSAN is difcult due to power, computation, and memory limitations of their nodes (i.e., sensors and actuators).To deal with this issue, WSAN usually incorporate other kinds of nodes with higher processing capabilities (e.g., base stations) in order to perform more complex operations.Tese unconstrained nodes, also known as smart nodes, are essential for satisfying CPS' requirements for more intelligent and autonomic behaviours as they grow in complexity.Upon these smart nodes, most of the advances made on the area of autonomic computing should be implemented.

Autonomic
Computing.Autonomic computing (AC) [9,10] emerged as a solution to deal with the increasing complexity of today's computing systems and human management limitations.Horn [9] defnes autonomic systems as sofware systems that mostly operate without human or external involvement according to a set of rules or policies; in other words, the systems are self-managed.Specifcally, IBM proposed the MAPE-K loop for supporting autonomic computing (see Figure 1).According to the MAPE-K loop, resources to be managed are composed of a set of sensors that provide information about the current state of the resources.Te model implements the following: the monitoring of the information (Monitor); the analysis to detect symptoms that need corrective action (Analyze); the planning of the action required to change the current state of the resource according to a set of goals or policies (Plan); and the execution of the plan through a set of efectors (Execute).Tese actions are operated over a knowledge base.Te MAPE-K loop model ofers the advantage of isolating the main concerns that any autonomic process has to provide.

Model-Driven Development (MDD).
MDD is a sofware development approach in which models can be managed and transformed to facilitate and automate tasks involved in development and evolution by employing high-level abstractions.Tis approach increases productivity and quality and reduces costs by automating basic activities in sofware development and evolution [5].Current quantitative analysis such as the work of Papotti et al. [6] shows that the main advantage of MDD is its code generation, demonstrating that development teams that use code generation are faster than those that applied manual coding.
Te OMG metaobject facility (MOF) 2.0 specifcation [12] defnes an architecture to support metamodelling and MDD.Its main purpose is the management of model descriptions at diferent levels of abstraction.Te four-layered metamodel architecture of MOF 2.0 can be described as follows (see Figure 2).Te M3 layer (meta-metamodel layer) defnes the abstract language used to describe the entities of the lower layer (metamodels).Te MOF specifcation proposes the MOF language as the abstract language for defning all types of metamodels, such as the metamodel of UML.Te M2 layer (metamodel layer) specifes the structure and semantics of the models defned at the lower layer.Te M1 layer (model layer) comprises the models that describe the data of the lower layer.Tese models are specifed using the primitives and relationships defned in the metamodel layer (M2).Finally, the M0 layer (information layer) consists of the instances of the models that are defned at the model layer (M1).

Model-Driven Engineering Process for Autonomic Sensor-Actuator Networks
Tis section presents MindCPS solution, a process based on models and model transformations designed to assist and guide the design and (semi)automatic development of CPS.Specifcally, we focus on CPS that ofer a set of services to users and businesses through autonomic control loopstypically composed of monitoring, analysis, planning, and execution tasks according to the MAPE-K loop defned in Section 2.2-which allow CPS to autonomously react to a wide range of situations in order to minimize human intervention.

doMaIN moDel for CPS (MindCPS)
. CPS are mainly constituted by the sensors embedded in devices that continuously collect measures from the environment in order to detect problems in the system.Tese problems are triggered through events in order to plan actions to execute them on the physical system through actuators.Te domain knowledge model MindCPS (doMaIN moDel for CPS) consists of a set of modelling primitives.It was designed to support the specifcation and defnition of the main concepts of a CPS, that is, sensors, measurements, events, problems, plans, actions, and actuators.Trough this model, one is able to specify the autonomic control loop of CPS from scratch as well as a change in existing CPS, dealing in a higher abstraction level with some issues that make this kind of systems complex.Some of these issues, mentioned above, are the heterogeneity of sensors and actuators and the defnition of complex conditions and patterns for problem detection and the respective plans to deal with them.In order to use the modelling primitives of MindCPS, it is necessary to design a domain-specifc language (DSL) through the defnition of a metamodel, its domain concepts, relationships, and rules (see layer M2 in Figure 2), as well as a graphical language representation.Using this graphical modelling primitives, engineers, even nonsofware engineers, can model the autonomic behaviour of CPS (see layer M1 in Figure 2) that conforms to the MindCPS metamodel (see layer M2 Figure 2).Te MindCPS metamodel is composed of a set of interrelated metaclasses.Tese metaclasses defne a set of properties and services for each concept considered in the model.On the one hand, metaclasses, their properties, and their relationships describe the structure and information that is necessary to defne the domain knowledge of CPS.On the other hand, the methods of metaclasses ofer the primitives to develop instances by creating, destroying, adding, or removing elements which are compliant with the constructors of the metamodel (most methods are omitted to gain readability).
Figure 3 shows a fragment of the MindCPS metamodel.Sensors are described by the metaclass Sensor.A sensor is characterized by an identifer, an IP address, a MAC address, and a communication protocol (see the attributes id, ip, mac, and protocol inside the metaclass Sensor).A sensor has the ability to acquire measurements (see the aggregation relationship acquired between the metaclasses Sensor and Measurement in Figure 3).Measurements are defned by the International Journal of Distributed Sensor Networks metaclass Measurement, which has two attributes: id and unit (measure unit).Te metaclasses Filter, SimpleFilter and ComplexFilter, defne the flters of measurements in order to detect when they are indicating a symptom associated with a problem (see these metaclasses and their relationships isFiltered bySimpleF and isFiltered byComplexF in Figure 3).Te abstract metaclass Filter has three attributes common to simple and complex flters: id, condition, and value, where the condition can be GreaterTan, LessTan, or EqualTo the value.Tese attributes are inherited by the metaclasses SimpleFilter and ComplexFilter.Whereas SimpleFilter models flters that can be applied only to one type of measurement, ComplexFilter defnes flters that are applied to more than one measurement.Terefore, the metaclass ComplexFilter has the attribute aggregation that permits it to specify an aggregation function (e.g., sum, diference, etc.) to be applied to a set of diferent measurements.Between the metaclasses Measurement and SimpleFilter, there is an association metaclass called SimpleFilteredMeasurement; and between the metaclasses Measurement and ComplexFilter, there is an association metaclass called ComplexFilteredMeasurement.Both metaclasses may indicate symptoms (see the relationships indicates and shows in Figure 3).
Te abstract metaclass Symptom defnes a symptom of a problem and it is characterized by an identifer (id).Four more attributes defne when a set of fltered measurements must be considered a symptom in terms of the number of times a measurement must satisfy a flter condition (numOccurrences); how much the measurement must vary over time in absolute terms (variation) or percentage (vari-ationPct); and the type of variation, positive or negative (increment).Symptoms are diferent depending on whether they are detected from real-time fltered measurements or from historical data stored by the system.Te metaclass RealTimeSymptom defnes the real-time symptoms that are detected within a certain period of time, identifed by the attribute timeSpan (see Figure 3), while the metaclass His-toricalDataSymptom historical-data symptoms are detected within an interval defned by a beginning and an end (see the attributes startInterval and endInterval in Figure 3).Analysis of historical-data symptoms can be triggered when a realtime symptom is detected (see the relationship triggers in Figure 3) or periodically according to a frequency (see the attribute frequency in Figure 3).
Symptoms are indications of problems (see the aggregation relationship hasSymptoms between the metaclasses Problem and Symptom in Figure 3).Problems are defned by means of the metaclass Problem, which has four attributes: id, severity, timespan, and timeUnit.Te attribute timespan refers to the time during which symptoms must be detected to consider that there is a problem.Problems are resolved through a plan (see the association relationship resolves between the metaclasses Problem and Plan Figure 3).Te metaclass Plan has three attributes: id, responseTime, and priority.Te attribute responseTime is the expected time for the efect of a plan to be noticeable.A plan can include other plans and/or can confict with other plans (see the association relationships includes and confictsWith).Plans perform one or more action/s to solve a problem (see the

«ordered» performs
OCL constraint: a symptom is caused by a simple íiltered measurement or a complex filtered measurement metaclass Action in Figure 3) according to a preestablished order (see the association relationship performs that has the stereotype ordered in Figure 3).Finally, actuators provide the actions that can be performed (see the aggregation relationship hasAction between the metaclass Actuator and Figure 3).Te metaclass Actuator includes the same attributes as the Sensor metaclass: id, ip, mac, and protocol.
Figure 4 shows the graphical language representation through an illustrative example A sensor that has the capability of measuring three variables-Measure1, Measure2, and Measure3-that are fltered through a set of flters; for example, a flter sets the condition that the value of Measure1 is greater than a constant X, while other flters set the condition that the addition (SUM) of Measure2 and Mea-sure3 is less than a constant X.Tese fltered measurements indicate symptoms associated with a problem.For example, a symptom is detected when 3 occurrences of Measure1 greater than X are received within 2 seconds with an increment of 2 units between them.Tis problem can be resolved through one of two possible plans.One of them is composed of two actions-Action 1 and Action 2-and has a time of response of 30 seconds.Finally, Figure 4 shows an actuator that can perform the two actions.
Te MindCPS DSL was implemented using the Epsilon generative modelling technologies (GMT) research project and was made available as an Eclipse plugin, the MindCPS tool (see snapshot in Figure 4).

Model-to-Code Transformation.
In MDD, models seek to automate development tasks through model transformations and thereby, reducing the development and/or adaptation time [6,7].Tis is why we defne a set of model-to-code transformations to generate the code and metadata necessary to support the development of a CPS that is specifed through the MindCPS model.To that end, a model-to-code transformation engine is the component in charge of automatically transforming a model into the code necessary to implement the core structure and behaviour of CPS.Tis core behaviour has a common part, that is, the common structure and code that is common to a general control loop for any kind of CPS, and a variable part, that is, the code that is variable according to information to be monitored, analysed, planned, and executed, which is modelled through a MindCPS model (e.g., the model shown in Figure 4).
To provide a visual of the common structure and code necessary for any kind of CPS according to our defnition, Figure 4: MindCPS graphical language supported by the MindCPS tool.
Figure 5 shows a layered view of the architecture that we have implemented for the construction of CPS' smart nodes.Te two-bottom layers of the architecture shown represent the devices of a specifc domain and the sensor/actuator network.Te communication middleware is in charge of acquiring raw data from sensors through a set of drivers that implement the communication protocols of the sensors (e.g., ZigBee, Bluetooth, 802.11, etc.).Te central layer implements a control loop that will provide low-level services for monitoring, analysis, planning, and execution, as well as for publishing and subscribing events.Tis layer is composed of controllers that are composed, in turn, of components.Controllers manage the lifecycle and the running context of their respective components.Hence, the MonitorController manages the lifecycle and the running context of specifc monitors.Each specifc Monitor implements the fltering of raw data in order to identify relevant data, the translation of raw data into comprehensible information conforming to the MindCPS model, and the routing, that is, the creation of events that are published through an event channel.Te AnalyserController manages the lifecycle and the running context of specifc analysers.Each specifc analyser processes real-time events-coming from the monitoring-through a CEP (complex event processing) engine and makes use of historical data for detecting anomalies and potential problems.Te Planner&ExecuterController manages the lifecycle and the running context of specifc planners and executers.Each specifc planner plans corrective actions to change the current state of the resource according to a set of goals and policies, while the executer executes the plan through a set of actuators.Finally, the event driven middleware implements the channel that interconnects monitors, analysers, planners, and executers through events.It can be implemented using diferent technologies, such as DDS (data distribution service for real-time systems) and JMS (Java message service).Tese technologies, based on the publish-subscribe paradigm, implement an event driven infrastructure which provide extremely loosely coupled and highly distributed nodes in order to construct scalable solutions and provide an implementation independent from the number of smart nodes of the CPS.Tis is due to the fact that the publisher of the event has no knowledge of the event's subsequent processing or the interested parties subscribed to the event (asynchronous publish-and-subscribe pattern) [13].
Te architecture defnition was guided by certain requirements and quality attributes that usually must be addressed when designing CPS.In the context of sofware architecture, quality attributes are the way to express the qualities we want an architecture to provide to the system or systems that will be built on it [14].We have focused on interoperability, modifability, and performance quality attributes.Interoperability and modifability are achieved thanks to main principles of the event driven SOA paradigm [15], which leverages the interaction between events and services providing fexibility and loose coupling, provides adaptability through service composition and orchestration, and supports encapsulation to integration at highly distributed systems.Performance is addressed by the inclusion of several architectural frameworks for distributed and real-time systems widely tested and used by industry.RTi DDS [16][17][18] and Esper CEP engine [19] have been proved to be highly efcient in terms of latency, throughput, and memory usage.
As mentioned above, this architecture provides the common structure for the smart nodes of CPS.Te behaviour and functionality that are variable depending on the specifc CPS are specifed through the MindCPS model.As described in Section 3.1, MindCPS supports the specifcation of the measures to be fltered and monitored, the symptoms to be analysed, the problems to be identifed, and the actions to be planned and executed.From the identifcation of the common and variable parts, it is possible to automatically develop the core behaviour of CPS.From this core control loop, it is possible to provide users and businesses with a wide range of smart applications and high-level services, such as realtime monitoring, alarm management, and decision support (see service layer in Figure 5).Finally, it will be necessary to manually implement the listeners dependent on the drivers of sensors and actuators (see protocol and drivers layer in Figure 5).Once common and variable parts of code to be generated have been identifed, model-to-code transformations are defned.Transformations can generate code in any language, such as Java and C#.Te task of defning the transformation is complex but can be reused for any CPS based on that language.Te difculty is in defning the frst transformation, as subsequent transformations are very similar.We have defned the transformation based on our background in CPS projects.Concretely, the model-to-code transformations were created using previously developed projects, and, therefore, most of the code has been previously tested in production.In detail, the model-to-code transformations we defned generate the following: (1) the code that implements a control loop to be deployed in the smart nodes of a CPS; specifcally, the transformation automatically generates Java code skeletons and composes the common code from a set of common code templates and the variable code from the information modelled in a MindCPS model; (2) the EPL (Event Processing Language) queries of an Esper CEP engine that implement the advanced analysis and processing of real-time events coming from monitored and fltered measurements of sensors; (3) the SQL queries of a database manager that implement the advanced analysis and processing of nonreal-time data coming from monitored and fltered measurements of external sources, services, or even sensors without real-time restrictions.

MindCPS into Practice.
Te design and development of CPS require frst modelling the embed sofware on physical objects (i.e., the smart nodes) that continuously acquire and collect information from the physical environment, which is processed-ofen in real time-to make decisions and act on the physical world through actuators.To that end, the MindCPS solution provides the modelling primitives for specifying the data to be monitored, the problems to be analysed, and the plans to be executed.Trough this specifcation, it is possible to automatically generate the code that implements the behaviour of the smart nodes of CPS. Figure 6 shows how the MDD process works to support the development process.CPS are specifed and confgured through the defnition of a MindCPS model (see label 1) that conforms to the MindCPS metamodel from which, through a model-to-code transformation (see label 2), three artefacts are generated: Java code, EPL, and SQL queries.Finally, the resulting system is executed (see label 3).

L.
MindCPS Te MDD approach supports the automatic generation of the code for new components-for example, a new monitor, analyser, or planner.Tis code conforms to the core components of the architecture shown in Figure 6.In this way, MindCPS solution simplifes the design and development of CPS, conceptualized as a set of smart nodes distributed throughout a WSAN that implement autonomic control loops for smart sensing and actuation.As a result, the efort invested to develop CPS using the MindCPS consists of (i) the time and efort that the engineers invest in defning the conceptual modelling of the CPS and (ii) the time and efort for implementing the code that is specifc of each of CPS, that is, the listeners dependent on the drivers of sensors and actuators.Using MindCPS the time and efort of developing the automatically generated code are minimum.
System complexity is also taken under control thanks to theMAPE-Kloop model.TeMAPE-Kloop model ofers the advantage of isolating the main concerns that any autonomic process has to provide.Te separation of concerns provided by the MAPE-K loop model entails a substantial reduction of interactions between sofware components that can be more easily handled.
Te automation of code generation provided by MindCPS solution also provides higher code quality and faster sofware design, development, and evolution.Since their components are decoupled and constructed for being reused for other systems, the transformations (code generation patterns) have been iteratively constructed from our experiences in CPS' construction in IMPONET and NEMO projects (see Section 1).

Experience Report
Te MindCPS MDD process is the result of the research initiated in the projects IMPONET and NEMO&CODED, as it has been previously mentioned.To illustrate the application of the MindCPS solution, we present the implementation of a demonstrator for smart metering with energy efciency capabilities (see Figure 7).
Te demonstrator, which we refer to as Arboleda, was deployed in a building located on the south campus of the Technical University of Madrid.Te Arboleda demonstrator was equipped with various artefacts; including sensors, smart grid nodes, gateways, and actuators.Te sensors included power, water, humidity and temperature meters, and a presence detector.Te actuators included a HVAC system controller and a photovoltaic generator PLC connected to a solar panel.Te Smart Node sofware components, including the automatically generated code, run on a Raspberry Pi model B (512 MB of RAM) connected through its 100 Mb Ethernet port to the LAN where the rest of the elements are installed.Tis Raspberry Pi is also equipped with a ZigBee Shield to allow the device communication via ZigBee protocol.It is remarkable that Raspberry Pi model B has a cost per year between 7$ and 15$ (24/7 running), which is fairly good in terms of power consumption.Figure 8 shows a fragment of a MindCPS that models the domain knowledge of the Arboleda demonstrator as follows.Te PowerMeter Building measures and records power consumption, maximum voltage, slip frequency, and phase angle, while the PowerMeter SolarPanel measures power output, voltage, slip frequency, and phase angle.Te resulting measures are fltered to detect symptoms and problems related to unusual consumption levels in the building, as well as synchronization failures (abnormalities of voltage and frequency between the corresponding phases of a solar panel output and grid supply) (see Unusual Consumption and Power Grid Synchronization Failure).For example, the problem of Power Grid Synchronization Failure is detected when the limits for synchronization are exceeded.Tese limits are as follows: phase angle is ±20 degrees (see maxPhaseAngleDif ), maximum voltage diference is 7% (see voltageDif ), and maximum slip frequency is 0.44% (see frequencyDif ).Tis problem is solved through a plan that consists of an action that synchronizes-that is, minimizes the diference in voltage, frequency, and phase angle between the corresponding phases of the solar panel output and grid supply-through a PLC connected to the solar panel (see the plan Repair Sync Failure).
Te temperature sensor measures temperature which is fltered (measurements greater than 22 C) to indicate a problem that we call Rapid Temperature Increase when 6 consecutive occurrences are detected within 1 minute with an increment of 2 C. Te Cooling Procedure plan generates an alarm and attempts to solve the problem by launching the Reduce Temperature action, provided by the HVAC System Controller.Finally, the sensor Occupancy Sensor measures the number of people inside the building.Te problem of Unusual Consumption is detected when two symptoms occur: (1) 5 measures of power consumption greater than 21.5 KWh are detected during a period of 30 minutes and (2) during the same 30-minute period, the building occupancy is low (under 15 people).As shown in Figure 8, the historical data analysis for detecting the symptom Few People in Building is triggered when an Over Average Consumption symptom is detected.Te problem Unusual Consumption is reported through a service that publishes the problem and associated symptoms to a website (see the plan Report Unusual Consumption).
Te MindCPS model identifes which measurements a smart grid node of the Arboleda demonstrator must be able to monitor and analyse in order to execute plans.Once this is accomplished, the code can be generated.Figure 9 shows an overview of the Java classes that are automatically (see solid rectangles) or semiautomatically (see dashed rectangles) generated for detecting and solving the problem Rapid Temperature Increase.Tree events, three publishers, and three subscribers are created in order to enable interaction between the automatically generated components: TemperatureMonitor, RapidTemperatureIncreaseAnalyzer, and CoolingProcedure-Plan.Event-based interactions between these publishers and subscribers provide the system functionality.Te MindCPS process generated 61 classes, 6573 lines of code, 11 running threads, 6 publishers, and 12 subscribers.Tese numbers could be low, but they are suitable for maintaining loose coupling between components and for implementing design patterns correctly.
In addition to the Java code, a key part of the demonstrator is the analysis and detection of problems-consumption abnormalities.Te analysers of this demonstrator are implemented on the Esper CEP engine, and thus EPL queries are also automatically generated.Pseudocode 1 shows the EPL query automatically generated for detecting the Rapid Te m p e r a t u r e I n c r e a s e problem.
Code generation can be even more complex in the case of the detection of historical-data symptoms.Although the components for the Unusual Consumption problem are generated in a similar way, the main diference lies in how the code for historical-data symptom detection is generated.Tis is due to the fact that not all database management systems support SQL clauses for pattern recognition.For example, Pseudocode 2 shows the Java method pseudocode for detecting the historical-data symptom Few People in Building and Pseudocode 3 shows the generated SQL query.Te method createQuery creates the query, extracting the interval from which the analysis must be carried out (see startInterval) Select peopleNumber, eventTimeStamp from OccupancyHistoricalData where eventTimeStamp > @startDateTime and eventTimeStamp < current timestamp order by eventTimeStamp asc Pseudocode 3: Generated SQL query for fewPeopleInBuilding symptom detection.based on the current system time.As endInterval is not defned, the end of the interval is determined by the current system time.Finally, the method applyAggregationFunction returns the number of matches for the searched pattern, applied over the executed query result.
Another issue that afects the time of generation is the number of smart nodes to be generated.Until now, we have modelled small and medium size CPS.However, to cope with the modelling of big CPS using MindCPS, in which the number of nodes undergoes an explosion in number, abstraction and parameterization techniques with diferent levels of generation will be implemented in the future.Tese techniques will allow modeling families, subsystems, and types of elements and then instantiating them by refnement in order to scale the creation of nodes as we have demonstrated in previous works [20].
Using the MindCPS model described in Figure 8, we were able to automatically generate most of the code necessary to implement the demonstrator for smart metering.Tis code will be deployed at the smart grid nodes of the Arboleda demonstrator (see the smart grid node in Figure 7).
To conclude this section, it is necessary to underline some limitations of the presented case study.Our testing scenario pursues to check the MDD generation and its feasibility in small/medium size CPS, although it is not able to measure performance in large-scale systems.We plan to measure performance and other quality attributes impact in complex CPS, providing metrics and accurate statistics, but this specifc work is out of the scope of this paper.

Related Work
Te main contribution of MindCPS is the adoption of MDD for the (semi)automatic construction of CPS.A few works were found regarding the modelling of this kind of system, particularly autonomic CPS that follow an MDD process.Prakash et al. [21] combine MDD and several autonomic computing principles in a diferent domain.Specifcally, they present a model-driven methodology for designing and verifying autonomic behaviours of future network architectures.Zein et al. [22] present a metamodelling approach to defne a DSL for smart sensor description for a deep-sea observatory.Tis approach is focused on defning a metamodel, while the work presented here goes two steps further in the MDD process by (1) defning a DSL by means of a graphical modelling tool and (2) performing model-to-code transformation.Te MindCPS metamodel defnes higher-level WSAN functionalities than the metamodel presented by Zein et al. [22].

Conclusions and Further Work
Te current work presents the MindCPS solution that supports and automates the design and development of CPS.Design is guided by a DSL for specifying the autonomic behaviour of CPS.(Semi)automatic development is supported by an MDD approach, specifcally by a model-to-code transformation whereby models that conform to the MindCPS DSL are transformed into (i) Java code that implements the autonomic control loop for smart sensing and actuation and communication through an event publish-subscribe middleware; (ii) the EPL queries of an Esper CEP engine that implement the advanced analysis and processing of real-time events coming from monitored and fltered measurements of sensors; and (iii) the SQL queries of a database manager that implement the advanced analysis and processing of non-realtime data coming from monitored and fltered measurements of external sources, services, or even sensors without realtime restrictions.
Te MindCPS solution was put into practice in a demonstrator for smart metering located in a building on the south campus of the Technical University of Madrid.With the implementation of this demonstrator, we were able to check the feasibility of the MindCPS solution and also refne and improve the model.
As further work, we are planning to provide a CPS framework with the capability of dynamic reconfguration, or even self -reconfguration, by adding mechanisms for safestopping in order to guarantee that the elements to be evolved at runtime are placed in safe state, avoiding the possibility that changes in these elements would introduce inconsistencies into the running system.UPM (Technical University of Madrid) through its researcher training program.

Figure 6 :
Figure 6: Overview of the MDD process.

1 Figure 8 :
Figure 8: A fragment of the MindCPS model of the CPS deployed at the Arboleda demonstrator.