How to Analyze Machines to Identify Standard Modules

Part 2 of Software Standardization for OEMs

Software Standardization for OEMs is a series of articles that explains, in a step-by-step way, how OEMs can standardize their automation software.

In the first part of the series, I introduced the concept of software standardization and explained the value of standardization for OEMs. If you missed that part of the series, you can find it here.

In this part of the series, I will explain how you can analyze current and past machines to identify standard software modules that can be used across many projects.

After identifying standard modules, we will go through the process of writing requirements for the modules.

The end result of this process is a spec sheet for each module to be created. This spec sheet is used as an input during the programming and testing of standard modules to ensure that the modules deliver the right functionality.

Analysis of the Machine

Robotic Palletizing Cell

The picture above shows the machine that we will be referring to throughout this series. It is a typical robotic palletizing cell.

In this article, we will decompose the machine into modules according to the IEC 81346–1 and IEC 61512–1 standard. We do this because the first step towards standardization is to analyze our machines to identify the modules that can be standardized.

The idea is to identify all of the modules that are used to make up the machine and determine which modules are reusable across many projects.

After identifying the modules which can be standardized, we’ll define requirements for these modules to create a specification sheet. This specification sheet is used as an input during the design phase when the modules are re-engineered to fit with the company standard.

There are many ways to decompose a machine into modules. The IEC 81346 standard, Industrial Systems, Plant and Equipment and Industrial Products — Structuring Principles and Reference Labelling, describes how to structure machines to create reference labels.

Many OEMs are already following this standard to create their reference labels, so it makes sense to use the same approach to analyze and decompose their machines.

The standard provides guidance on how to decompose machines according to a specific criteria, known as an aspect. Typically, machines are decomposed according to their functional aspects although they could be decomposed using any number of other aspects.

In this example, we’ll use the functional aspect to decompose the robotic palletizing cell into functional modules.

We can decompose the robotic palletizing cell into the following functional units:

  • Belt conveyor 1
  • Belt conveyor 2
  • Belt conveyor 3
  • Belt conveyor 4
  • Belt conveyor 5
  • Belt conveyor 6
  • Machine vision system
  • Robot
  • Pallet position 1
  • Pallet position 2
  • Safety fence
  • HMI
  • Control panel

We can already see that some functional units are used repeatedly in the machine such as conveyor belts and pallet positions.

More importantly, we can see that almost all of the functional units we identified may be applicable to other machines that we build in the future.

These functional units can be further decomposed into elemental modules and groupings of elemental modules.

The IEC 61512–1 standard describes how to decompose subsystems according to the ISA’s Physical Model. According to the standard, subsystems can be decomposed into Equipment Modules and Control Modules.

An Equipment Module is a functional grouping of individual control units that can perform a finite number of processing activities.

A Control Module is the lowest level of equipment processing, typically representing a single sensor or actuator.

We can apply this decomposition strategy to the Conveyor Belt functional unit that we previously identified.

The conveyors in our example contain two Control Modules — a photoelectric cell and a drive. This is illustrated in the image below.

Decomposition of the Conveyor Belt functional unit

As mentioned previously, the Control Modules are the lowest part of the Physical Model defined in IEC 61512–1. The Control Modules which we have identified are responsible for interfacing with hardware.

To achieve the desired functionality of the Conveyor Belt functional unit, the Control Modules interface with Equipment Modules. These Equipment Modules contain the logic that creates the behavior of the functional unit.

In this example, the Photo Electric Cell Control Module interfaces with a Transport Logic Equipment Module to create the transport logic for the conveyor belt.

In a simple system, this Transport Logic Equipment Module may interface with the upstream conveyor to allow new products onto the conveyor when the Photo Electric Sensor is not occupied.

A second Equipment Module may provide the logic to control the drive and run the physical conveyor when sending products to the downstream conveyor or receiving products from the upstream conveyor.

The relationship between the Control Modules, Equipment Modules, and the Functional Unit are shown in the image below.

Relationship between Control Modules, Equipment Modules, and Functional Units

This decomposition process is repeated for every Subsystem Unit in the machines that are analyzed. In doing so, we create a complete list of Control Modules, Equipment Modules, and Functional Units used in the machines.

When you repeat this analysis on many machines, you get a picture of what Control Modules, Equipment Modules, and Functional Units are repeatedly used in projects.

Obviously, the modules which are used more frequently should be a higher priority in your standardization plan.

Defining Requirements

For each Control Module, Equipment Module, and Functional Unit identified, we must define the requirements for the module. These requirements define how the module will work and what functionality should be realized by the module. Broadly, the requirements for a module can be classified as functional (what the module does) and non-functional (how the module works to achieve the desired functionality).

Requirements are the basis for programming the module and later, for testing the software block created to ensure that it works as planned.

Let’s define the requirements for the Photoelectric Cell to see how the process of defining requirements works.

The Photoelectric Cell Control Module provides the interface between the PLC and a physical photoelectric cell. It is

Functional Requirements

  • The Control Module must read the input of a physical Photoelectric Cell
  • The Control Module must detect when a Photoelectric Cell is flickering (almost out of alignment, dirt build-up, obstruction on the belt)
  • The Control Module must detect when the Photo Electric Cell is damaged and report the error
  • The Control Module must have a configurable on and off delay

Non-functional Requirements

  • The Control Module must not add more than 2 microseconds to the scan time when called

Putting it Together

The end result of the analysis phase is a set of prioritized specification sheets, with one for each software module to be created. Each specification sheet contains a description of the module as well as a set of functional and non-functional requirements for the module.

These specification sheets will be used in the design, programming, and testing phases to ensure that the module is correctly implemented.

Conclusion

In the analysis phase, we decompose current and previous machines into modules and define the requirements for these modules.

What’s really interesting about this analysis is that even special-purpose OEMs begin to realize that they can reuse more of their software than they thought. Although they may not be able to standardize on a machine level, most OEMs can create standard software for Control Modules, Equipment Modules, and even Functional Units that can be reused across projects.

By standardizing these Control Modules and Equipment Modules, machine builders can already begin to increase their efficiency and software quality.

What’s Next?

In the next part of the series, we’ll take one of the Control Modules identified and create a software design for the module. This design will serve as the basis for programming the module and highlight some best practices for creating software modules that can be easily reused across projects.

We’ll also implement the design by creating a software block for the Control Module that can be added to the company library.

Be sure to sign up to the mailing list below to be notified when the next part is published.

Automation Engineer, Technology Enthusiast, Freelance/Consulting. Official website: https://www.kb-controls.io/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store