AMBER: Advanced Mother Board for Embedded systems pRototyping

3.1 The philosophy

In today’s scenario, most of the embedded solutions are based on an SBC design. Such platforms are composed of a single printed circuit where the microprocessor, the memory, and several peripherals are installed. While the computational part of the system is completely embedded on the platform, some extensions can be created by using available GPIOs. In this case, the development of a new and extended platform enabling new features requires redesigning the most critical part of the system: the processing part. For instance, considering the BeagleBone Black solution, analyzed in Section 2, several add-ons, the capes, have been created by the community. The development of an industrial-oriented solution fully integrating a developed cape would require a complete redesign of the system, including the processor and memory which require significant design due to the high-frequency buses used. To overcome the limits of an SBC-based design, AMBER aims at decoupling the processing components from the peripherals. Such approach is realized considering a System-on-Module based design concept. A SOM is a board level circuit that integrates primary system functions in a single module to be installed on a hosting mother board. The AMBER solution embraces this design concept and pushes them towards new levels introducing the possibility of creating board level circuits for additional peripherals: Extender modules to be plugged into the main board of the system. In a nutshell, AMBER can be defined as an advanced mother board for embedded systems prototyping aiming at filling the gap between solutions that can be used by technology enthusiasts, research laboratories, and the industry. The proposed AMBER approach, on the one hand, allows reaching an extreme modularity while, on the other hand, enables a fast prototyping of industrial solutions. In fact, by leveraging on SOMs, no critical parts of the system must be redesigned. SOMs with different features and prices are widely available on the market. Moreover, if an Extender module has been carefully designed and developed in a prototyping step, only the hosting main board solution needs to be developed to meet the industrial requirements, thus requiring an industrial-oriented customization of the AMBER solution. In its philosophy, AMBER proposes to leverage on Extender modules pluggable into sockets populated with a large number of communication buses. This approach allows AMBER to provide an extreme flexibility since a large number of electronic devices provided by different vendors can be used. Moreover, another interesting feature of the AMBER solution is the scalability. This feature is mainly enabled by the exploited SOM-based approach. In fact, SOM solutions exploiting multi-core architectures allow the use of AMBER in a large set of applications requiring different computational capabilities. The AMBER philosophy based on System-on-Modules and Extender modules is shown in Fig. 1 where a socket able to host the SOM, two sockets populated with Extender modules, and a third socket available for additional modules are reported.

In addition to the three main AMBER characteristics reported above: modularity, flexibility, and scalability, a fourth to be added is the openness. In fact, since AMBER aims at fostering the development of industrial solutions starting from systems developed by technology enthusiasts and research laboratories, it has been envisioned since the beginning as a fully open solution.

3.2 The hardware design choices

Moving from design philosophy to real embedded solutions, several design choices must be done to reach trade-offs among final costs, interest from the community, the lifetime of the solution, and ability to be updated. In this respect, the first implementation choice has been focused on the System-on-Module. The Variscite SOMs [18], and in particular those based on the NXP i.MX6 [19] family of microprocessors, have been selected among available solutions on the market. Such a choice is the result of analysis related to advantages and drawbacks in early standardization efforts, available architecture, prices, and product longevity. Moreover, Variscite is a worldwide leader in SOM design and manufacturing, thus being able to provide a broad range of solutions at low cost while guaranteeing more than 10 years of longevity. Although Variscite products do not support the recent released Qseven standard [20] aiming at standardizing the form factor and the communication buses to be exported on the SOM socket, the provided solutions embed on the SOM popular communication modules (e.g., WiFi, BLE). Moreover, thanks to a SOM design enhancing a full compatibility among solutions exploiting the same microprocessor architecture, multi-core capabilities can be easily exploited (i.e., a new SOM with the same pinout and embedding a microprocessor with a greater number of cores can work in a plug&play manner). All these characteristics make Variscite solutions very appealing to those customers willing to focus their attention on the software side of their products while using already embedded popular communication systems.

Concerning the Extender modules, instead, the attention has been mainly focused on the Extender socket definition, since the design of a new Extender module is something that should be realized by people willing to add a new feature. In any case, a correct and simple design of the Extender socket is necessary to foster and facilitate the development of new Extender modules. For this reason, a popular and low-cost socket connector has been considered, while exporting 50 GPIOs related to the following communication buses: I2C, SPI, UART, and USB. GPIOs related to MiniPCIe and Ethernet have not been exported on the Extender socket since they are considered conventional buses and interfaces to be hosted on the main board. AMBER hosts three Extender sockets to let developers combine several functionalities. Moreover, their number allow keeping the AMBER dimensions reasonable, thus allowing its installation in real laboratory testbeds.

The AMBER board in its prototype and finalized design is reported in Fig. 2. In the picture can be recognized the three Extender sockets able to host Extender modules, the SOM, in particular, the Variscite VAR-SOM-SOLO/DUAL CPU, and the MiniPCIe socket. In the Extender socket number 1 can be noticed a simple Extender module exporting all available buses and GPIOs, thus enabling a fast laboratory prototyping of new Extender modules from the community.

3.3 The BSP availability

The BSP plays a key role in the success and spread of a new embedded solution. If, on the one hand, the BSP must be an effective and powerful implementation of specific support code letting a complete software customization of the system, on the other hand, it must also be managed by non-expert users. The AMBER BSP enables a user to easily create a customized Linux distribution based on the 4.1.15 kernel version and the 2015.04 version of U-boot. Even though the selected Linux kernel is not one of the latest officially released, it is maintained by both NXP and Variscite, thus taking advantage from both communities of developers. Regarding the Linux distribution, two of them are supported in the AMBER BSP: Debian Jessie and Yocto with Morty core. The former is a popular distribution with a large availability of software packages for the ARM architecture, thus being a suitable solution for hobbyists and research laboratories willing to focus their attention on applications. The latter enables an advanced and optimized customization of the system. Yocto permits to create a custom Linux distribution by selecting necessary packages and recompiling them. Companies mainly use Linux distributions created through Yocto for the final commissioning of a developed solution. In addition to the two Linux distributions reported above, the Android Nougat 7.1.1 has been recently released. As for the hardware implementation, also the choice for the maintained BSP (U-boot, Kernel version, Linux distribution, Android version) goes in the direction of fostering an easy reuse of applications and functionalities to foster an immediate industrial reuse.

4.1 Industrial Internet of Things and AMBER role

In recent years the Internet popularity has experienced exponential growth, thus fostering in the academic and industrial communities the so-called IoT paradigm [21]. According to such a paradigm, in the near future, billion of devices will be part of the global Internet network to create smart environments in a significant number of scenarios, thus improving human lifestyle and efficiency in their working activities.

The use of IoT technologies in industrial environments is at the pillars of the fourth industrial revolution, known in the literature as Industry 4.0 [22, 23]. IIoT systems can be successfully used to create effective smart factories in which enhanced levels of efficiency can be reached. IoT devices can be pervasively used to collect data on the field with the aim of improving productivity through advanced automatic processes [24] and safety through a deeper knowledge of worker position [25] and reducing equipment faults through fast event detection capabilities [26]. Through the use of wireless and wired devices with monitoring and actuating capabilities, advanced applications avoiding the human-in-the-loop constraints can be created, thus moving towards effective cyber-physical-systems.

An advanced IIoT system with sensing and actuation capabilities is composed of three primary layers, from the bottom to the top: (i) the sensing and actuation layer, (ii) the gateway layer, and the (iii) server layer. Such architecture, depicted in Fig. 3, is a generalization of what is reported in [27] considering the whole intelligence distributed in all the components of the system, thus exploiting the so-called Fog Computing approach [28]. At the lowest layer, sensors, actuators, and other devices are considered to be smart objects, that is devices able to sense/actuate, process, and communicate, thus implementing part of the intelligence of the system according to their capabilities. At the gateway layer, instead, powerful devices are necessary to manage multiple communication technologies, both wired and wireless, as well as to perform advanced data analysis (i.e., machine learning algorithms, big data analysis) on a reduced time window, and real-time controls by leveraging on connected sensors and actuators. The greater the intelligence of the system implemented in the gateway, the faster the reaction against the occurrence of certain events. The upper layer is composed of server units able to store data collected by the two levels below, as well as to process them to extract advanced knowledge (i.e., long-term analysis). Ideally, such servers can reside in the cloud.

In the reported architecture, AMBER can be successfully used as an IoT gateway, since, how it has been reported in [29], it has all the necessary and required characteristics. Moreover, it can be easily and successfully used in an industrial scenario to develop advanced industrial control systems fully supporting the architecture depicted in Fig. 3. In fact, along with the capabilities of supporting multiple wireless technologies by developing specific Extender modules, AMBER is a suitable choice to control devices through wired field buses requiring real-time constraints. Thanks to proper Extender modules and low-level software adaptations, a wide number of industrial buses based on twisted pairs can be supported (e.g., Profibus, ModBus), as well as real-time Ethernet field buses (e.g., Powerlink, EtherCAT, Profinet).

4.2 Use case, system design, and implementation

In this article, AMBER is proposed as an IIoT gateway solution targeted to an industrial control system where the thermal control of critical equipment installed in the environment is necessary. An example is a production line in which several machines must be controlled in real-time, and afterwards, an additional thermal control making use of new generation wireless sensors is required to be installed. In this scenario, the gateway of the system must be able to manage and control all the installed actuators in real-time. Moreover, at the same time, it must receive data from wireless temperature sensors to react and take the proper action in the lowest amount of time (i.e., when the temperature of a sensor is above a certain threshold a motor in production line must be turned off to reach a safe condition). To notify of dangerous conditions in real-time to actuators compliant with new generation field buses based on Ethernet technology the Powerlink [30] standard has been selected. Moreover, battery-powered temperature sensors based on the Bluetooth Low Energy [31] technology have been considered to implement the monitoring part of the system.

Powerlink is an open-source industrial protocol designed and developed to reach reliable and deterministic real-time communications for automation. The main idea behind Powerlink is to avoid collisions over the Ethernet channel by introducing a master-slave approach. The bus master is the Managing Node (MN), while all the other nodes participating in the network are called Control Nodes (CN). The Powerlink standard acts cyclically with a bus cycle, is determined at configuration time, and divided into two phases. The former is the isochronous phase in which time critical information is sent from MN to CNs in a scheduled manner, thus avoiding collisions and meeting real-time constraints. The latter, instead, is the asynchronous phase in which all nodes can communicate to each other by using the standard Ethernet protocol. This phase is used to send non time-critical data. Bluetooth Low Energy is a wireless technology mainly developed to reach ultra low-power performance, thus being a suitable choice for a wide range of applications in which battery-powered devices require to be connected in a network. BLE applications range from healthcare, fitness, domotic to industrial applications, where new devices can be installed for retrofitting purposes. The BLE standard specifies the functionality for enabling bidirectional communications between two devices possibly acting as master or slave. Master nodes (e.g., laptop, smartphone, system gateways) usually scan for other devices, while a slave node sends data (e.g., sensor devices) whenever it is necessary. A slave is usually a battery-powered device in a sleep mode state, and it periodically wakes up to be discovered by a master.

In the considered use case, AMBER is configured as an IIoT gateway acting as MN node in the Powerlink network and master node in the wireless segment of the system. Moreover, to follow the architecture reported in Fig. 3, AMBER is wired connected to the Internet (i.e., connection towards the server layer) in order to publish possible events, or data, in remote servers. The high-level system design is depicted in Fig. 4 where at the center of the picture has been reported the AMBER with the necessary hardware modifications, some Powerlink actuators connected through Ethernet on the left, and BLE sensors on the right. From a hardware point of view, a new Extender module has been designed in order to enable an additional Gigabit Ethernet communication on AMBER. Such LAN Extender module is reported at the bottom of Fig. 5, while the top shows the IIoT AMBER mounting the extender. This additional Ethernet peripheral is used by AMBER to control Powerlink actuators, while the Texas Instruments Wilink WL183xMOD [32] module embedded in the selected Variscite SOM, the VAR-SOM-SOLO/DUAL based on a dual-core architecture, is used to interact with BLE sensors. Regarding the actuators, no real hardware solutions have been used in the laboratory implementation of the system since they are closed solutions in which no software customizations are possible to add special functions to be used for performance evaluation purposes (e.g., execution time measurements). To overcome this limitation, a laptop with a Linux OS has been used. Conversely, for the BLE segment of the system, real devices have been selected, in particular the TI Sensortag [33] device. Such a device is based on a new generation of microcontrollers, the TI CC2650 [34], implementing a double protocol stack: BLE [6] and IEEE802.15.4 [35]. Moreover, the device embeds several sensors (i.e., temperature, humidity, accelerometer, light, pressure), thus being a suitable solution to be used in a wide range of IoT applications. From a software point of view, AMBER runs a Debian Jessie distribution in which the openPowerlink [36] stack has been ported. Moreover, an application reading data from BLE sensors and sending actuation controls (AMBER is configured as a MN Powerlink node) upon the occurrence of a certain event (i.e., temperature value above a certain threshold) has been developed. The openPowerlink stack is executed even on the laptop acting as CN node in the Powerlink network. Regarding the BLE sensors, no software customizations have been developed, and the official TI code released with the devices have been used, thus focusing all development efforts on the AMBER application in charge of reading data from these sensors. Since the Powerlink stack runs as a microprocessor application, the LAN Extender is completely agnostic to the enhanced protocol mechanisms and it can be successfully used to support other real-time Ethernet field buses such as EtherCAT and Profinet.

Although in the described use case BLE sensors have been considered, thanks to the AMBER modularity and flexibility features, the envisioned IIoT system can be easily extended. In the industrial environment, a common standard used in wireless communications is the IEEE802.15.4. Such a standard is at the basis of WirelessHART [37] and 6LoWPAN-based [26] industrial monitoring solutions. To support IEEE802.15.4 based communications, while enhancing the monitoring part of the system, an additional extender can be plugged into available slots. The IEEE802.15.4 Extender reported in Fig. 6 leverages on AMBER modularity and flexibility by using an additional socket in which necessaries communication buses have been connected to support the selected transceiver.

Since additional IIoT interfaces and managing processes require additional computational resources, more powerful SOMs can be used, thus enabling scalability features in the proposed solution. For instance, the presented AMBER configuration targeted to IIoT scenarios can be upgraded by using a quad core SOM, the Variscite VAR-SOM-MX6. Moreover, thanks to the AMBER modularity, higher scalability levels can be reached by considering Extenders embedding additional microprocessors or microcontrollers, thus exploiting hardware and software Asymmetric Multi-Processor (AMP) solutions [38].

4.3 Performance evaluation

Since the whole system has been targeted to a monitoring and control IIoT use case in which a thermal criticality triggers an actuation event, a key parameter to evaluate is the actuation time delay. This key performance parameter, evaluated as the time from which the temperature data request is sent until the actuation is performed, is a global indication of the system responsiveness. To measure the actuation time delay, all the components of the system (i.e., AMBER and the laptop emulating the actuator) have been synchronized by means of an external NTP (Network Time Protocol) server. Moreover, the Powerlink network has been configured with a cycle time of 100 ms (isochronous plus asynchronous phases). More than 1000 experiments have been executed, and all results are summarized by the histogram reported in Fig. 7. The reported actuation time delay includes the time to perform the temperature request to a particular sensor, the time to compare such a value with a priori imposed threshold, and the time in which the actuation notification reaches the laptop emulating the actuator node of the Powerlink network. In a real application, an additional delay due to the actuator response time must be considered. For instance, considering electromechanical actuators characterized by response times less than 12 ms [39], such a value can be added to results in Fig. 7 to perform a worst case analysis of the system.

The actuation time delay distribution presents a Gaussian shape with a mean value close to 235 ms. A worst case analysis of the reported results shows that the highest delay is lower than 268 ms. Such a value proves the high degree of responsiveness of the system, as well as the likely choice of using AMBER as IIoT gateway solution. It must be stressed again that despite the fact that the presented system has been developed for laboratory experimentation, the developed LAN Extender module and all the software can be easily reused to enable a fast prototype of a powerful and integrated industrial solution.