Machine modularization

Article#: 00070

Date: 2021-10-08

Author: Radim

How do we properly divide the whole machine program into modules?
We have to look at the machine, its structure, which machine parts it consists of, how it is equipped with sensors and actuators and what the process and the functions of the machine look like.

A module performs a function of the machine or a machine part and encapsulates everything that is required for the function. It usually has some inputs, outputs, internal functions, and may contain other subordinate modules.

The module is a tool with which we control a part of the machine.
The module collects information from peripheral devices or subordinate modules, processes it, and issues commands to these peripheral devices or subordinate modules.
It also provides information about its status for parent modules and for the visualization and executes commands coming from the parent modules and the visualization.

The modules are like boxes that we put into each other.
Parent module contains one or more subordinate modules.
With this modularization we create a hierarchical structure of the machine program.
There is no limit to the number of levels in the structure.
In general, at higher levels we are more abstract and detached from the real physical devices, but if we need we can connect peripheral devices at any level (See "Button Z" in the figure below.).

Let's start the modularization with the lowest level of the machine - with sensors and actuators. (See "Module A" and "Module B" in the figure below.)

Then we need to find a meaningful grouping of the lowest level modules.
We group some modules together when we see that they can perform a sub-function of the machine. This creates the second level modules. (See "Module C" in the figure below.)

The correct grouping of the modules can be recognized by the fact that the parent module has everything (all necessary subordinate modules) available that it needs for its function.
This is the right encapsulation and abstraction that makes the program properly structured.

We put small boxes in a bigger box. Then we put bigger boxes in an even bigger box and so on. And finally, the biggest box contains exactly everything what we require and thus represents our machine / plant or entire system.

Figure: Nesting of modules; Module interfaces

Explanation of the figure:
The figure is an example of the nesting of the modules of the lowest hierarchical level (Module A and Module B) in the parent module (Module C).
The figure also shows 3 different types of module interfaces: interface to peripheral devices, interface to parent module and interface to visualization (Human Machine Interface).

The ellipse represents the programmed function of the module.
The arrows pointing into the module represent the defined inputs of the module.
The arrows pointing out of the module represent the defined outputs of the module.

Module A is a module at the lowest level of the hierarchical structure.
This module has defined inputs for a sensor connection. (This connection can be e.g. a 4-20mA analog signal.)
The module also has a defined interface (inputs and outputs) for communication with the parent module and outputs for providing information to the visualization (Human Machine Interface).

Module B is also a module at the lowest level of the hierarchical structure.
This module has defined inputs and outputs for connecting an actuator. (This connection can be e.g. a Profibus signal.)
The module also has a defined interface (inputs and outputs) for communication with the parent module and outputs for providing information to the visualization (Human Machine Interface).

Module C is the parent module for modules A and B.
Module C has a digital input for connecting a button.
Module C also has a defined interface (inputs and outputs) for communication with a parent module.
Module C has inputs for getting commands from the visualization and outputs for providing information to the visualization (Human Machine Interface).

© Radim-Automation, 2020–2025. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).

Related previous articles:

• Modular software architecture
• Hardware concept
• A good concept = Complete set of suitable solutions
• Design machines with a focus on user's abilities and needs
• Why do automation projects fail?
• Collect all the requirements and sort them!
• Who will operate?
• Functional and intuitive HMI
• Use a usefull styleguide!
• Write and accept only readable code!
• Appoint a representative!
• HMI and PLC applications should grow together
• Do you really want to start with this?
• I can see what you can not see
• More than just start and stop
• Safety first!
• Do the right things and do them right!
• Define test scenarios and test cases continuously!
• Don't make it worse!
• Keep the answers to the question "Why"
• Everything is difficult until it becomes easy
• Get and stay in the flow!
• Stay alert!
• What does the customer need?
• Don't disappoint your customer!
• Ask questions!
• Develop a sense of responsibility!
• Get the things done with a small, motivated team!
• Focus on target!
• Think on paper!
• 9 women can't make a baby in a month
• Sharpen your axe before you start felling!
• Check the result!
• Keep it simple!
• Don't leave a work package half-finished!
• Success is not a matter of coincidence
• Development is evolution
• Follow the vision!
• Don't neglect and don't skip any step!
• Transparency and reliability
• From an idea to a consistent system

Related next articles:

• Knowledge gained from a completed project is priceless
• Variable names
• Choice of programming language
• Visual modeling
• Documentation issues
• Safety relays versus safety PLC
• Design considerations for effective HMIS
• Clear signals
• It doesn't work without sensors
• Event logger as the very first function implemented in the program
• My boss was a hero
• Version control system
• PLC network diagram
• Maintain order in the program code
• Dream of a platform-independent PLC program
• Keep everything you need together
• High Performance HMI
• The false illusion of rapid progress

Comment#: 00001

Date: 2021-10-13

User: Radim

If you think that a subordinate module has two parent modules that both need to control this one subordinate module, then the subordinate module should not be placed in any of the parent modules, but directly next to them on the same level as the parent modules. The module that is located in the hierarchical structure above the two parent modules and controls them should also control the common module according to the states of the two parent modules.

Comment#: 00002

Date: 2021-10-13

User: Radim

Stay flexible in the program structure! Even if you have collected all requirements and the process experts claim that "it is final like this", there are cases in which it is necessary to change these "final" things again during commissioning and initial tests.

Comment#: 00003

Date: 2021-10-17

User: Radim

Problem analysis is easy with a suitable modular architecture. Since a higher-level module always controls the inputs and processes the outputs of its subordinate modules, it is easy to find out at which interface the information is not being transmitted.

Comment#: 00004

Date: 2021-10-19

User: Radim

In order to properly encapsulate all things that the module needs for its functionality (but nothing else), it is good to imagine that we have to remove the module from the program / project as easily as possible and use it in another program / project.
Imagine a module would like to be used by a colleague in his program ... Is the module encapsulated accordingly, can the module be adopted as easily as possible?

Comment#: 00005

Date: 2021-10-19

User: Radim

Commissioning the machine is much faster if the program is properly structured in modules. For example, no detailed I/O test is necessary but it is sufficient to test the function of each module in manual mode with the machine. Only if the machine does not fulfill the intended function we have to look for a problem in the assignment of the variables, wiring and pneumatics.

Comment#: 00006

Date: 2021-10-20

User: Radim

The development of each module is a separate sub-project within the main project and should encompass all phases of the development cycle, i.e. analysis, programming, testing, etc.

Comment#: 00007

Date: 2021-10-20

User: Radim

Answers to these questions can help with modularization:

1. What elements are there?

2. How is the relationship between the elements?

3. How are the elements connected to the PLC?

4. What information do the elements provide?

5. Who is this information for?

6. In which states can the elements be switched?

7. Who controls the elements?

8. Under which conditions do we want to switch the elements into their possible states?

9. Under which conditions may the elements not be switched to certain states?