Modern manufacturing automation systems are complex engineering products that fulfill functions such as material handling, distribution, and processing. For this reason, their design is mostly the result of engineering professionals. Of course, the automation system is both hardware and software; however, the software is usually considered as ancillary. The role of software designers is that of supporting the automation engineers, particularly in implementing a distributed system with some autonomy in the different subsystems.

Among the possible solutions to software design, the authors choose to use the model-based engineering (MBE) approach, defined in section 2 by four main requirements:

R1: the functional requirements are developed together with the design of the automation system;

R2: the complex network of sensors, actuators, and controllers is defined with the communication interfaces;

R3: the reuse of proven solutions is encouraged; and

R4: software is deployed on the on-board information processing hardware of the devices.

After presenting in section 3 related works about modeling automation systems, which often are based on object-oriented tools such as the systems modeling language (SysML) and the unified modeling language (UML), the authors develop a notation and a prototype of their system, defined as a set of nodes plus a communication system.

Section 4 is about the workflow, which is divided into four levels of hierarchy. Using the top-down approach, the functional requirements are defined first, so the structure of the software application can be defined.

Section 5 is about the development of MBE. The functional requirements are decomposed into automation functions, each defined as aggregation of software parts called function blocks (FBs). During the development of the system the model is generated at each step in the workflow. The communication interfaces are defined with increasing details at each level, according to R2.

Function patterns describe different functions that could be selected to fulfill an automation function; moreover, deployment patterns indicate the alternative distributions of functions over the distributed architecture, making R3 feasible. When all the FBs and nodes have been defined, the FBs are mapped to the nodes, fulfilling R4.

A method, called functional application design for distributed automation systems (FAVA), is explained for a simple plant consisting of three moving belts synchronized with sensors and actuators, but other manufacturing systems have been considered, and the tool is implemented in SysML.

The comparison of FAVA to traditional methods using continuous function chart (CFC), a widely adopted programmable logic controller (PLC) language, is discussed in section 6. It reports about three experiments where four groups of participants made the design of an automation task. In the first experiment, some used FAVA notation and others CFC, finding that the FAVA notation resulted in a more complete system architecture. In another experiment, some used only the FAVA notation, and others used the FAVA-advanced implemented tool; the latter group obtained better results. The last experiment used FAVA-advanced versus FAVA-full, which includes also the deployment pattern, and confirmed the value of this extra feature.

This paper is an example of how to apply some well-known ideas about software development in an area, automation plants, where traditional ad hoc solutions are preferred. The method, however, cannot be considered as a universal solution. FAVA is about design, but it lacks any consideration about many software parameters, such as time complexity, so it seems appropriate for tasks where the time requirements could easily be fulfilled.

Anyhow FAVA, or some successor, could be a step toward a more precisely defined and formalized approach.