Architecting IoT Applications with SysADL

Transcription

1 2017 IEEE International Conference on Software Architecture Workshops Architecting IoT Applications with SysADL Jair Leite, Thais Batista Computer Science Department Federal University of Rio Grande do Norte (UFRN) Natal RN, Brazil Abstract In this paper we present how architecting IoT applications using an Architecture Description Language (ADL), SysADL, that supports: (i) the architectural modeling of heterogeneous IoT devices; (ii) easy modification of the architectural description; (iii) specifying scalable architectural model to satisfy the scalability non-functional property of the architectural description to allow increasing the number of IoT devices. Keywords IoT Applications, Architecture, SysADL, Scalability I. INTRODUCTION In the Internet of Thing (IoT) paradigm, systems are typically composed of an increasing number of interconnected heterogeneous devices. The structure of their architecture is dynamic with elements inserted and removed during system lifetime. Architecture, in the context of IoT systems, is the final organization and configuration of the network of elements along with the operational specification of the them and of the protocols used in their communication. Data format specification, as well, is another important feature that is needed to allow the communication in a heterogeneous configuration [2]. The architecture of IoT systems, similar to the Internet, is very heterogeneous, changeable, and evolutionary. No reference architecture seems to account for all systems implementation. In this context, the design of the architecture of IoT systems requires a language to support these specificities. An architectural description language (ADL) [1] for modeling IoT applications should support: modeling heterogeneous devices as abstract elements; modeling devices as active and autonomous; the description of connections and communication between and undetermined number of heterogeneous devices; easy modification of the architectural description to indicate or reflect system architecture modifications and evolution; the architectural specification of a scalable architectural model to satisfy the scalability nonfunctional property, allowing the rise in the number of constituent devices; In this paper we present an ADL, SysADL [3,4,5], that fits the above requirements by providing architectural abstractions proper for modeling IoT applications elements. Flavio Oquendo IRISA UMR CNRS Université Bretagne Sud (UBS) Vannes, France flavio.oquendo@irisa.fr Particularly, this paper focus on how to architect IoT applications using SysADL and how it supports the specification of architecture that are: (i) easy to modify; (ii) scalable; and (iii) support the connection of heterogeneous devices. It is worthwhile to mention that IEEE Standards Association is currently working on the definition on architectural frameworks (P2413) 1 for IoT that follows the ISO/IEC standard. That framework in not ready yet but since it follows the standard, the IoT architectures that are derived from the framework could be represented in SysADL as it also follows the ISO/IEC standard. This paper is structured as follows. Section 2 briefly summarizes SysADL. Section 3 presents the process of architecting IoT applications with SysADL. Section 4 presents a discussion about how presents SysADL supports non-funtional requirements for IoT. Section 5 presents related work. Finally, section 6 draws the final remarks of this paper. II. OVERVIEW OF SYSADL SysADL is an ADL based on the concepts of SysML (Systems Modeling Language) 2. SysML is a general purpose modeling language for systems engineering. It is a subset of UML 2 (Unified Modeling Language) 3 with some extensions to be more proper to specify, design, analyze, and verify complex systems. SysADL was designed based on SysML to preserve a system-oriented approach. Therefore, using SysADL engineers can design architecture models to softwareintensive system preserving the main concepts from system engineering, but extending them to the concepts used by the software architecture community, namely components, connectors, and configurations. SysADL concepts are suitable to model a runtime perspective of software-intensive system in an abstract level, using the component abstraction to model distinct elements: system, subsystem, process, thread, controller (PLC), sensor, or actuator /17 $ IEEE DOI /ICSAW

2 SysADL follows the ISO/IEC Standard Systems and Software Engineering Architecture description 4 providing several viewpoints and model kinds to allow different perspectives for system modeling. The structural viewpoint describes system components, its ports, connectors, and how connectors links components in a configuration. Composite components have a configuration of connected components. The structural viewpoint is described using SysML diagrams Block Definition Diagrams (BDD) and Internal Block Diagrams (IBD) as in SysML. SysADL also follows SysML and UML requiring the definition of elements types and the use of instances. The behavioral viewpoint specifies the activities and constraints for each component and connector. SysADL requires at least one activity for each simple component or connector. When there is more the one activity for a component, an alternative (exclusive) behavior specification is given for that activity. The behavioral viewpoint also requires the specification of port protocols that govern how data flows in and out the ports. An activity can have one or more action. Actions have a start-stop behavior and can concurrently determine the behavior of the component. The activity is described using the Activity Diagram adapted from SysML The behavior of composite components is derived from the composition of each activity for each internal component. Each activity must be constrained by pre- and postconditions equations. SysADL constraints can be described as a SysML <<constraints>> or as a Parametric Diagram, also adapted from SysML (see Figure 1). The executable viewpoint brings to SysADL the expressive power of specifying the execution details for each action. The executable description code allows SysADL models to be executed. SysADL relies on an adapted version of the OMG Action Language for Foundational UML (ALF) 5. Beyond these three viewpoints, SysADL also inherit the Requirements Diagrams to allow the specification of architectural significant functional and extra-functional requirements, including stakeholders concerns. Use Case Diagrams can also be used to specify stakeholders concerns. UML 2 Packages Diagrams are also used to organize SysADL models according to each viewpoint. In summary, Figure 1 shows the main SysADL diagrams and their relationship with SysML. It shows that SysADL and SysML share the package diagram, the requirements diagram and the use case diagram. It also shows that SysADL specializes the Block Definition Diagram, the Internal Block Diagram, the Activity Diagram, and the Parametric Diagram. These diagrams are specialized to represent architectural abstractions (components, ports, connectors, configuration, among others). In the next section we briefly explain the diagrams. A detailed explanation can be found in previous papers [3][4] and in SysADL book [5]. Figure 1. The relationship between SysADL and SysML Diagrams III. ARCHITECTING IOT APPLICATIONS To exemplify the use of SysADL to model IoT systems, we use a Weather Monitoring System (WMS) composed of several different sensors connected in a wireless network. In our description, we do not detail the aspects that are typical to a wireless sensor network, such as network protocol, power consumption and others. We focus on the architectural aspects structure or configuration of the WMS components, their behavior and the interactions among them. The Weather Monitoring System uses remote weather stations units to sense temperature, humidity and atmosphere information in an urban geographic area (about 200 km 2 ). Each weather station (ws) has an identification number and a manually set location (latitude and longitude). The station communicates with other station via Wi-Fi connection. Each ws receives data from other station, aggregate them with its own data, and send them to the next station in the sequence. A central weather processing subsystem receives composite data from the weather station network to process them to be used for several other applications. As we said before, our goal in using that example in this paper is to show how to model it using SysADL, to show its facilities in terms of expressivity of the IoT devices and connections, and how easy is to represent the dynamics of the architecture, particularly non-funcional properties such as modifiability and scalability. A. Structural Viewpoint - Definitions SysADL requires the definition of all elements before it can be used (as an instance) in the system architecture. Figure 2 shows the definition of an atmosphere pressure sensor. The AtmPressureSensorCP component is a boundary component with an out port to provide atmospheric pressure values. We define that element specifying its out port. A boundary component, represented in gray color, is a used to 93

3 represent devices that interact with the environment. We do not need to describe their internal structure or behavior,. We just need to specify what are the data types their in or out ports require or provide, respectively We also need to define the port specifying the type of the data that flows out. Figure 3 shows the definition of the AtmPressureOPT port that flows out values of the type AtmPressure. The definition of the port requires the indication of the type of value that flows in or out. In this port, AtmPressure flows out. The definition of the value type requires the definition of dimension and unit. Figure 2. The definition of the AtmPressureSensorCP In SysADL, following SysML, all definitions should be described in the Block Definition Diagrams (BDD). We can define several BDD s to organize the definitions of the architectural elements used in a description. As a good practice, we recommend different BDD s for the definitions of data and value types, ports, components, connections, activities, actions, equations, and executables. Figure 5, Figure 6, and Figure 7 show the definitions of the structural element types of the Weather Monitoring System. Figure 4 shows the definition of all data and value types of the Weather Monitoring System. We define value types to the Atmospheric Pressure with unit in atm; to the Relative Humidity in percentage; and to Temperature, which can be in Celsius and in Fahrenheit units. Value Types are used to represent scientific and engineering measurements time, length, mass, temperature, etc. whereas Data Types are used to computer data structures arrays, records, classes, etc. We define WeatherStation, WeatherStationDT, and LocationDT as data types to organize the value types in structures that are sent through ports and connectors among the components where they are processed. Figure 3. The definition of the AtmPressureOPT put port and the AtmPressure value type. Names in SysADL follow some conventions. We use the CP suffix for component; OPT for out ports; IPT for in ports; CN for connectors; and others that we introduce later in this paper. Figure 5. The definition of ports types. Figure 4. The definition of value and data types Figure 5 depicts the definition of the ports used in the components. In each definition, we need to specify the port type name, its direction (in or out), and the type of data that flows through the port. The figure shows the definition of in ports and out ports to Temperature, Humidity and Atmospheric Pressure value types and also a port to the array (WeatherStationDT) of WeatherStation data structure. It is important to note that we need to define data and value types before defining ports. 94

4 We also need to define ports before defining components that use them, as we can see in Figure 6. Our system has six components. The WeatherStationCP component is composed of a WSDataAggregatorCP component and three boundary components TemperatureSensorCP, HumiditySensorCP, and AtmPressureSensorCP. Boundary components are used to represent the components interfacing with the external environment sensors, actuators, user interfaces, etc. As we said before, we do not need to describe their internal structure or behavior. The WSDataAggregatorCP component is in charge of aggregating the new values provided by sensors with the previous data from other WeatherStationsCP. The WeatherProcessingSubsystemCP component receives data to calculate average values and send them to other components via its out ports (TemperatureOPT, HumidityOPT, and AtmPressureOPT). B. Structural Viewpoint - Configurations In SysADL, we define the architectural structure of a system or the internal structure of a component, as a configuration using an Internal Block Diagram (IBD). A configuration describes how instances of components are connected with others instances via connectors. The instances can have names to identify themselves. Figure 7. The definition of the connectors types. Figure 6. The components types of the Weather Monitoring System We also use port definitions to define connectors. Figure 7 shows the definition of the connectors of our example. In a connector definition, a port is a participant in an association. The WeatherStationDTCN connects a component with a port of the WeatherStationDTOPT type (the source) to a component with a WeatherStationDTIPT port (the destination). We also should specify the data or value type a connector can convey as an association type, and it must be of a compatible type of the participant ports. In this case, WeatherStationDT is the data type the connector can convey from its source to the destination. Figure 8. The configuration of the WeatherStationCP component. Figure 8 shows the internal structure (configuration) of the WeatherStationCP component. Following its definition specified in Figure 6, the component has one instance of the TemperatureSensorCP, namely the ts component. The hs:humiditysensorcp, the aps:atmpressurecp; and the wsda:wsdataaggregatorcp are the other instances in this configuration. The IBD in Figure 8 also shows the 95

5 connectors instances used to connect the components. Each sensor component sends their respective values to a particular port in the WSDataAggregatorCP component. That component aggregates the values in a data structure and sends it via the op:weatherstationdtopt out port. Figure 9 shows a possible architecture configuration for the Weather Monitoring System. In this example, we have three instances of WeatherStationCP components connected in a sequence and one of them connect to an instance of the WeatherProcessingSubsystemsCP component. In the diagram (Figure 10), we can see four in parameters, one out parameters, and one action. An activity must have a least one action. The t:temperature, h:humidity, and ap:atmpressure in parameters specifies the data values provided in the WSDataAggregatorCP component ports. The ad:appendwsdataan action add these values to the array data structure received as a wsdata in parameter (from the ip:weatherstationdtipt port) and send the result to the newwsdata out parameter (from the op:weatherstationdtopt port). Figure 10. The behavior of the WSDataAggregatorCP component. IV. SYSADL SUPPORT FOR NON-FUNCIONAL REQUIREMENTS SysADL provide support for some important nonfunctional requirements for IoT System. In this section, we explain using our example (WMS) how SysADL architectures can be easily modified to support architectural reconfigurations of IoT systems, to support connection of heterogeneous IoT devices, and to support scalability in the number of IoT devices. Figure 9. An architecture to the Weather Monitoring System (Architecture 1). C. Behavioral Viewpoint The behavior of a software architecture refers to the way the elements perform activities and interactions to achieve the required system functionality. SysADL is based on the dataflow-based operational semantics to specify how software architecture elements perform activities to consume and produce data. Each activity is defined in terms of actions, control flows and data flows that govern their executions. Each action has a simple behavior that receives input parameters and executes from begin to end without interruptions to calculate the output parameters. We exemplify a behavioral specification of the WSDataAggregatorCP component using an activity diagram (see the component definition in Figure 6 and its use in Figure 8). Figure 10 shows the AggregateWSDataAC activity diagram. We use as a convention the verb form of the component name followed by a AC suffix to indicate that it is an activity. The header also specifies that the activity is a behavior specification for the WSDataAggregatorDataCP component inside square brackets [] as optional information. A. Modifiability SysADL is a dataflow-based language, which means it benefits the design of dataflow-driven architectures. Components are the locus of execution for data processes and connectors are the locus for data communication. When an architect specifies an architecture using SysADL he/she focus on how component process data and how data flows from one component port to other component port through the connectors. There is no message call in SysADL comparing to the object-oriented architectural paradigm. The dataflow paradigm and the low coupling between the components benefits the design of architectures that facilitate modifications in the resulting systems 6. A SysADL component has no dependency of internal processes of others components. Each component has the responsibility to process the data that it receives in its in ports and to send the results to its out ports. The component does not know what components are providing or consuming data. Another important characteristic of SysADL is the specification of the cardinality of its elements. The default 6 We are referring to modification in the resulting running system and not in the model. 96

6 cardinality is 1, which means one instance of a defined element. However, we can specify an element of a cardinality * (any integer) or a range, for example, 0..2; 0..*; 1..*; etc. In this paper, we define two new versions of the architecture of the WMS using specification of the cardinality of elements. In the second architecture specification of the WMS, we define a new connector WeatherStationDTCN-2 that allows the connection of one or more sources ports to one destination port. Figure 11 shows the modification in the specification (compare with the previous connector in Figure 7). This new connector definition allows the architect to specify a new architecture with several WeatherStationCP components chains connected to the WeatherProcessingSubSystemCP. Figure 12 shows an architecture with two chains connected to the WeatherProcessingSubSystemCP component. It makes no difference to the processing capabilities. We consider the easy of modification as the cost of changes resulted from a required change. It is also know as the ripple effect or impact a single desired change demand. For instance, if we need to change a port of a component instance in an architecture, we may need to change the linked connectors and internal elements. The new architecture specification is easier to modify since the architect can easily add several component chains. We do not need to modify the behavior specification of the WeatherProcessingSubSystemCP since its WeatherStationDTIPT port receives data from the multiples connected component in a sequence. This example shows that SysADL supports the specification of system architecture that are easy to modify. However it is important to note that system architecture implementation must rigorously follow the specification using technologies such as wireless links that allows manyto-one connections. 12 allows the architect to increase the number of WeatherStationCP components to a magnitude of hundreds. Figure 12. A new architecture with two weather stations to one WeatherProcessingSubsystemCP component (Architecture 2). However, in terms of processing performance, the system can lose efficiency since the WeatherProcessingSubSystemCP component must perform hundreds of data in a sequence. An alternative to improve performance is to change the WeatherProcessingSubSystemCP to concurrently process the WeatherStationDT data. We need to modify the WeatherProcessingSubSystemCP component to have one-ormany ports to receive several connections from different chains. Figure 13 shows the new WeatherProcessingSubSystemCP component with one-ormany (1..*) ports. We also need to modify the internal structure of that component to have multiples instances of the internal component that receive data from each port and can concurrently process data. Unfortunately, due to a lack of space in this paper we cannot show the internal structure and the behavior of the WeatherProcessingSubSystemCP component. Figure 11. A new connector allowing many-to-one weather stations connections. B. Scalability Scalability refers to the degree to which a system can be scaled for increasing operational usage. In Software Architecture, scalability refers to how the architecture can be scaled with an increasing number of component that may be of several orders of magnitude without loose operation efficiency. In IoT system, it is common to raise the number of connected devices, typically sensors and actuators. The modified architecture we show in Figure 11 and Figure Figure 13. A new WeatherProcessingSubsystemCP with one or many ports. Figure 14 shows a third architecture to the WMS with the new component. As we can see, we have two chains of WeatherStationCP components, each one is connected to a different port. 97

7 C. Interoperabity Interoperability is the quality referring to the system capability to interact with heterogeneous devices. Adaptability and portability are also related qualities (nonfunctional requirements). When we have an adaptation capability, we can design systems that can interoperate with heterogeneous devices or can run in a different environment (portability). Figure 14. A new architecture with the Weather Station allowing many to one weather stations connections (Architecture 3). SysADL connectors have the architectural role of conveying data from one or more component port to other ones. However, SysADL connectors are first-class elements that can have processing capabilities without losing their communication roles. We can specify a behavior to transform data to adapt to new situations. That capability allows the architect to define connectors as adapters, proxies, bridges or brokers to improve connection capabilities. Figure 15. A new connector that convert Fahrenheit temperature to Celsius unit. The FahrenheitToCelsiusCN connector has the capability of converting from Fahrenheit to Celsius temperature. Figure 15 shows the definition of the connector and Figure 16 depicts its behavior in an activity diagram. We can now connect temperature sensors that provide temperature in different units specifying a connector to deal with conversions. Our example here is a partial demonstration of that capability. Figure 16. A new connector that convert Fahrenheit temperature to Celsius unit. V. RELATED WORK There are a number of ADLs proposed by the software architecture community. However, in general, ADLs that are generic enough to be used for modeling IoT-based systems lack support for describing behavior and execution, as SysADL does. Wright [6] supports behavior specification using CSP, that is a static process algebra. Wright enables the description of behavior, but it does not support the detailed specification of the internal behavior of components and connectors, for example, action specifications. In addition, it lacks graphical notation as SysADL does. AADL [7] is designed for describing architectures of hard real-time embedded systems in the avionics and automotive industry. Supported by a UML Profile as frontend, AADL lacks a formal semantics. AADL is, therefore, complementary to SysADL that is a general purpose ADL for software-intensive systems (including software-only systems), where the role of AADL in the development lifecycle could naturally be to refine SysADL models for describing the low-level architectural design of the embedded software components. Indeed, AADL is too lowlevel in software/hardware terms to be used outside of the domain of real-time systems. In addition to progress the state-of-the-art, SysADL is in line with findings of the survey published by Malavolta et al. [8], reporting an investigation about the industrial use of architectural languages. The survey includes participants of 48 practitioners from 40 different IT companies in 15 countries. According to the practitioners, formal ADLs have rarely been integrated into the software life cycle and they are rarely used in industrial settings mainly because of the effort to learn them and the specialized competencies to use them, among other reasons. The industry mostly relies on semi-formal notations and UML/UML profiles are largely used. They argue that ADLs need to be practical and to provide multiple views and cross-view consistency, reducing the learning curve for using them. We adopt these practitioner suggestions and propose SysADL as an extension of the new unified systems modeling language, i.e. SysML, to reach the broad community that uses SysML and also UML and reduce the effort to start using it. We also define multiple views and the integration and the correspondence between the views. VI. FINAL REMARKS The goal of an Architecture Description Language (ADL) is to allow the specification of an architectural model that meets functional and non-functional requirements of a system. For modeling IoT systems, composed of a myriad of heterogeneous objects and physical devices, an ADL must support the definition of the objects and devices and their interconnection, as well as to allow an easy modification of the architecture and the specification of an architectural model with the ability of increasing the number of constituent objects and devices. 98

8 In this paper we discussed how a SysML-based ADL (SysADL) can support the abovementioned requirements of IoT system modeling. With the three views of SysADL it is possible to specify the structure, behavior, and execution of an architectural model. IoT physical devices are modeled as components and their interconnections are modeled as connectors. We illustrated the use of SysADL in modeling the structural and behavioral of an IoT system, the Weather Monitoring System (WMS) composed of several different sensors, and discussed how some non-functional requirements essential to IoT systems are achieved using SysADL. There are other possible analyses we can do using SysADL in a near future. We can analyze the correctness and completeness of the architecture specification using SysADL Studio, a tool for modeling, analysis and execution. The tool is almost finished and is available for download 7. Performance is another non-functional requirement we can analyze. If we define metrics and reference values for each component and connector executions we can infer the global value of all component and connectors instance in the architecture. ACKNOWLEDGMENT The authors thank to Eduardo Silva and Lidiane dos Santos for their comments and support on SysADL development. Jair Leite thanks to CAPES, Thais Batista thanks to ANP/PRH-22 and CNPq (process / and process /2016-4), and Flavio Oquendo thanks to CNPq (process /2013-7) for additional financial support. REFERENCES [1] Bass, L., P. Clements, and R. Kazman. Software Architecture in Practice. 2nd ed. Prentice-Hall, [2] Bleakley, G. The Role of Simulation in Model-based Systems Engineering for Complex Cyber-Physical Systems. Interconnect, [3] F. Oquendo, J. Leite and T. Batista, SysADL: A SysML Profile for Software Architecture Description. Proceedings of the 7th European Conference on Software Architecture (ECSA), [4] F. Oquendo, J. Leite and T. Batista, "Specifying Architecture Behavior with SysADL", 13th Working IEEE/IFIP Conf. on Software Architecture (WICSA), [5] F. Oquendo, J. Leite and T. Batista. Software Architecture in Action: Designing and Executing Architectural Models with SysADL Grounded on the OMG SysML Standard. Springer, [6] Allen, R.: A Formal Approach to Software Architecture, Ph.D. Thesis, Carnegie Mellon University, CMU-CS , [7] Olveczky, P., Baronat, A., Meseguer, J.; Formal Semantics and Analysis of Behavioral AADL Models in Real-Time Maude. Proceedings of the 30th IFIP WG 6.1 International conference on Formal Techniques for Distributed Systems, pp 47-62, [8] Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., Tang, A.: What Industry Needs from Architectural Languages: A Survey. IEEE Transactions on Software Engineering, Vol. 39, No. 6, consiste.dimap.ufrn.br/sysadl/ 99