# Architecting and Deploying IoT Smart Applications: A Performance-Oriented Approach
## 3 Architecting and Deploying IoT Smart Applications  
A complete solution for IoT smart applications requires different software, hardware, and communication technologies working together and integrating a variety of platforms, components, services, and applications. These technologies play different roles and provide functions that operate in different perspectives of the scenarios addressed by smart applications. Figure 1 depicts our proposed IoTecture, a generic 5-layer architecture based on our previous experience with the development of IoT smart applications [4; 49]. We recognize that a myriad of different layered architectures may be conceived having in mind different target applications. Nevertheless, IoTecture is the outcome of both an analysis of the literature (Section 2) and an iterative refinement process, and as such, it is effectively used in the specification of pilot deployment scenarios, as well as performance analysis studies. Compared to the 5-layer IoT architecture [12; 13; 14], our 5-layer one explicitly adds support for highly distributed data management functions and separates physical and data-driven models from application services. Also, by clearly identifying and separating components that are logically bound to the data, model, and service layers, IoTecture actively helps the deployment of IoT smart applications over different distributed locations in the mist, fog, and cloud. From a software architecture point of view, components of different layers are implemented by services--actually encapsulated into Docker containers with an exposed API, therefore microservices. Components inside each layer serve as representative examples of different alternatives that may vary according to characteristics, requirements, and constraints of applications and users. * Layer 1 (L1-Device): Sensors, actuators, and communication technologies--both wired and wireless--make up the lowest layer of the IoT architecture. Devices are sensors and actuators that represent IoT things. Figure 1 depicts some examples of Layer 1 components, such as industrial robots, that have many sensors to track their actions, and actuators to control engines that make them move according to different degrees of freedom, both exchanging messages with a smart industry application via wired and wireless communication technologies. * Layer 2 (L2-Transport): Collecting data from sensors, making it available to data management functions, receiving commands from application models, and sending them to actuators require a good deal of intermediate components to make it happen. Figure 1 depicts some examples of generic data transport functions for sensing and actuation purposes, such as: (a) IoT protocol (e.g., MQTT [50]) that sends data from IP speaking devices to place where they are transformed or filtered either by other components of this layer or by data management components; (b) IoT protocol translator (e.g., FIWARE IoT Agent) converts data from IoT protocol format (e.g., byte stream for MQTT) into its internal format within data management components (e.g., NGSI/JSON [29] for FIWARE) and vice-versa; (c) Sensor data endpoint (e.g., ChirpStack [34]) transports, unpacks and decodes data for specific IoT wireless communication technologies such as LPWAN [16]; (d) Device register deals with the myriad of connected devices; (e) Data encryption and Authentication, Authorization, and Accounting (AAA) is pervasively necessary for IoT communications and included in Layer 2. A general function of data security and network/service management are transversal functions, as all layers pervasively needed them (not represented in Figure 1, though). * Layer 3 (L3-Data): Every stage of any end-to-end IoT data flow needs to deal with data in different ways, such as storing, retrieving, distributing, transforming, and filtering.