# Development of a Novel Open Control System Implementation Method under Industrial IoT
## 1 Introduction  
The closed architecture of modern control systems in industrial automation has two meanings: the monolith of control software and the infrastructure dependency of control software, as Figure 1 presents. Generally, users cannot modify the control software's functionality to adapt to production orders or migrate the control software to other platforms to make full use of infrastructures (e.g., computing, storage, networking, operating system, etc.). Not only that, the closed architecture results in a stand-alone operation pattern of control systems. That is, one control system often couples with one actuator tightly. For instance, each machine tool has a computer numerical control system (CNC) as its proprietary brain to control its behaviors, as Figure 1 shows. In this context, users fail to equip actuators dynamically; instead, they need to purchase, install, commission, and maintain multiple similar or even the same control systems to equip actuators. Along with the complexity and scale of control software increasing, modern control systems are more and more closed, impeding them from adapting to new infrastructure paradigms in the industrial IoT to better respond to the mass customization challenge. An open control architecture is proposed to break the closed architecture of modern control systems. According to the \"Technical Committee of Open Systems\" of the IEEE, an open system is defined as follows: \"An open system provides capabilities that enable properly implemented applications to run on a variety of platforms from multiple vendors, interoperate with other system applications and present a consistent style of interaction with the user\". [PERSON] et al. suggest four criteria to estimate the openness of a control system [1]:* Portability: Control tasks can be used on different platforms without any changes, while maintaining their capabilities. * Extendibility: A varying number of control tasks can run on a platform without any conflicts. * Interoperability: Control tasks work together in a consistent manner and can interchange data in a defined way. * Scalability: Depending on the requirements of the user, the functionality of the control task and performance and size of the hardware can be adapted. Over the past three decades, the open control architecture has been discussed extensively, with many open control prototypes developed. A common approach to constructing open control systems is to decompose the control domain into a set of control tasks, implement control tasks as control components according to a certain component model (e.g., CORBA Component Model, Microsoft Component Model, etc. ), and then, develop a control prototype by composing control components in a specific structural pattern (e.g., layer architecture, microkernel architecture, etc.) [2; 3; 4]. In this case, openness is theoretically implemented by adding, removing, or replacing control components. Actually, however, these component-based open control prototypes do not have a high openness. To be specific, the lack of a control task granularity standard and the lack of a uniform component model to implement control tasks decrease the extensibility and interoperability of control tasks. The widely used off-the-shelf component models are often language- (or runtime-) dependent, which decreases the portability and scalability of control tasks. Moreover, control components may suffer from the \"DLL Hell\" issue, which occurs when the control prototype at runtime is trying to use an incompatible version of the control component than the one against which it was compiled. Furthermore, control components often deploy on a PC platform or a PC+board platform, making it hard for the component-based open control prototypes to take advantage of the ubiquitous infrastructure resources in the industrial IoT. A detailed review of the component-based open control prototype was presented in the authors' previous work [5].