Modular software architecture

Article#: 00068

Date: 2021-09-20

Author: Radim

Before we start programming, let's figure out how we're going to divide the program.

What do we gain if we divide the program properly?

The program code is divided into several shorter parts (modules). Each of these modules fulfills a specific function. The function is programmed only once in the module, but the module can be used several times in the entire program. This eliminates the need to write or copy the same code multiple times, which makes writing, debugging and modifying of the code easier.

The module is clear and easy to understand as the code is not long and only affects one feature.

The module is encapsulated, independent and fully fulfills the function. It is therefore easy to use in another project as well.

The module has a clearly defined input and output interface. With this interface we connect the module to the higher-level module, which writes the setpoints and commands into the module via the input interface and reads the actual values and states of the module via the output interface.

Appropriately named input and outpt module interface variables already indicate the function of the module.

The defined interface is excellent for testing the functionality of the module during development and also during commissioning.

If necessary, the program can easily be expanded with additional modules with new functions.

The entire program is structured and clear.

Several programmers can work on a program at the same time without conflict, since each one is working on a different module.

The work (programming, debugging, testing, documenting, troubleshooting, expanding, etc.) is efficient.

Be careful! Improperly designed architecture can later be a huge, unsolvable problem. If the program architecture is bad, even the best programming techniques cannot save the result.

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

Related previous articles:

• Think critically!
• Learn from your journey!
• 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!
• Everything is difficult until it becomes easy
• Realize every good idea ASAP!
• 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
• Don't hide any problem!
• Check the result!
• Keep it simple!
• Don't leave a work package half-finished!
• Success is not a matter of coincidence
• Choose the right tool!
• 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:

• Machine modularization
• 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
• Event logger as the very first function implemented in the program
• Diagnostic tools
• My boss was a hero
• Version control system
• PLC network diagram
• Keep the documentation up to date throughout the project
• Maintain order in the program code
• Make backups, make small changes and test a lot
• Dream of a platform-independent PLC program
• Keep everything you need together
• HMI - Have a consistent style
• Choosing an HMI display
• The false illusion of rapid progress
• HMI layout and correct display size
• HMI layout design
• HMI navigation
• HMI - back and forward navigation buttons
• HMI – Don’t hide anything
• What makes an HMI intuitive?

Comment#: 00001

Date: 2021-09-22

User: JLee

Good point. Clearly annotating comments are necessary. In case of working with multiple programmers, come up with a common debug tag/bit (in case of ladder logic) assigned to each programmer so everyone knows someone’s still debugging.

Comment#: 00002

Date: 2021-09-25

User: Radim

I can see a great similarity between the house building project and the industrial machine automation project.

1. We need to get an idea of what the result will be, what it will be used for, and how big it will be.

2. We have to gather all the necessary requirements.

3. Depending on the size of the building / program, it is necessary to select a sufficiently large property / a sufficiently powerful PLC.

4. It is necessary to design a suitable architecture and plans / SW architecture and concept.

5. We connect technical networks to the property, taking into account the availability at the respective location. / We select other electrical components based on their compatibility with the selected PLC.

6. We need to build solid foundations for the house. / We have to program a reliable lowest program layer (hardware abstraction layer and general functions).

7. Then we can build the rest according to the requirements and plans.

8. If someone makes a new requirement now, it can only be built into the building / program if this requirement corresponds to the proposed architecture.

9. With the wrong architecture or poor foundations, even the best bricklayer / programmer cannot build the idealized building / program.

Comment#: 00003

Date: 2021-10-04

User: Radim

Even a simple machine or system can be designed and programmed in such a complex way that its diagnosis and expansion is only possible with extreme effort and a high risk of introducing new unwanted errors.
Do you believe?

Comment#: 00004

Date: 2021-10-19

User: Radim

It is better to write a modular program that is easily expandable in the future than a large monolithic program that contains all possible functions.
A large monolithic program block is difficult to modify because it contains a large number of dependencies and "hidden" rules.

Comment#: 00005

Date: 2021-10-20

User: Radim

The dividing of the machine program into modules can also be useful for visualization. In the visualization it is sometimes necessary to have several views. A modular view is a view that shows information about the entire machine in a structured manner.

Comment#: 00006

Date: 2021-10-20

User: Radim

With a correspondingly modular structure of the machine electronics, it is possible to test the machine and put it into operation part by part.

Comment#: 00007

Date: 2022-07-28

User: Radim

"As a result of the increasing trend to make mechanically engineered systems as flexible as possible, it has become essential to change existing programs in such a way that modular machine concepts are also reflected in the software. As a result, modularization is becoming the guiding principle for designing the programs of the future. Modularized software comprises modules that are fully functional and tested as independent entities, but they can be combined to create a single functional unit within different machines."
- Michael Braun and Wolfang Horn. Publicis Pixelpark Erlangen (2017). Object-Oriented Programming with SIMOTION.

Comment#: 00008

Date: 2023-06-08

User: Radim

"Investments in good code quality and good architecture are sustainable investments. Over 80% of development work is maintenance work and changes to existing code. Prof. Niklaus Wirth once said that SW is not written for the compiler, but for people who have to maintain the code. If the question of "quick and dirty" arises, the bearability of the "technical debt" must also be taken into account, because at some point the debt becomes unbearable or so great that a "fresh start" becomes cheaper. In terms of insurance, this is referred to as a “total loss”. In the case of “quick and dirty solutions”, people often “muddle” in the same style over and over again. In addition to existing bad codes, other "spaghetti lines" are no longer noticeable, a free pass...

This is how a vicious circle begins, because with the growing "technical debt", the development speed also slows down - due to unreadable and bad code. This delays the completion of new features and the project has to live with explosively increasing opportunity costs."
Translated from:
- https://blog.noser.com/kennen-sie-ihre-technische-schuld-wir-unterstuetzen-sie-bei-der-rueckzahlung/

Comment#: 00009

Date: 2023-09-27

User: Radim

"By continuously improving the design of code, we make it easier and easier to work with.
This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently add new features.
If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code."

- Joshua Kerievsky. Addison-Wesley (2004). Refactoring to Patterns.

Comment#: 00011

Date: 2024-01-05

User: Radim

Let's speed things up!

One man needs one hour to dig a hole 1 meter deep, 1 meter wide and 1 meter long. How much time does it take if you engage 10 men?

ChatGPT: "If one man can dig a hole that is 1 meter deep, 1 meter wide, and 1 meter long in one hour, and you have 10 men working simultaneously, you can divide the time by the number of men to find the total time it takes for the group to complete the task.

So, it would take 1 hour / 10 men = 0.1 hours (or 6 minutes) for the group of 10 men to dig the hole."

Do you agree with ChatGPT's answer?