Object Oriented Design in Industrial Automation - Example

When I was a PLC programmer, object oriented programming was an unknown concept for me.  I did not mind about it since I have become a PC programmer.

In this post, I would like to talk about some benefits of object oriented programming with a simple case study.

An object is described as a computer representation of an existing real world thing or event. Object orinted programming languages gives the opportunity of dealing with these virtual objects, however if you don't design your system as 'object oriented', you can't use the benefits of object oriented approach.

Many PLC programmers have their programming library, most of the times they 'copy and paste' their rungs from previous or existing projects in to the new projects.

"DRY -  Don't repeat yourself" philosophy  is against for information duplication because duplication may increase the difficulty of change and decrease inconsistency. So, DRY philosophy should be agains 'copy and paste'.

Object oriented design helps you to not to repeat yourself.

Before giving an example, I would like to tell some concepts in object oriented programming, first concept is 'class'.

Class can be considered as a set of objects, and classes are also objects too. For example, a book can be considered as a class made up of multiple page objects. There are some properties of the book such as page count or colour. Also, there are some possible actions can be done with a book, such as reading, or placing on a shelf.
However, in programming classes are not object at all. They are definitons of object and its properties. With this point of view, a class can be considered just as a cookie cutter.

Once you design a cookie cutter, and you produce many cookies with it. The disadvantage of object oriented design can be seen here, if you are going to make only one or two cookies, building a cookie cutter is not convenient. But if you want to make dozens of cookies, a cookie cutter may be a good idea.

It is also possible to extend capabilities or properties of a class and make a superior class. For example, a dictionary is a special book that you can search words in it. So we can talk about the class 'dictionary' which can be derrived from class 'book'. All the actions can be done with a book is still valid with a dictionary, we can read it or place it on a shelf. This is inheritance, which aids reuse of code.

When you read a book, you don't mind how that book was written or how that book was published. You only see the pages of the book which can be considered as 'interface'. This is the principal of information hiding and mostly named as encapsulation.
Information hiding principle has two advantages:
- Programmer does not need to be so experienced
- It is difficult to corrupt the object, because its internal structure is protected

Let's back to our 'book' object. We are able to read books including dictionaries, almanacs, novels etc. Reading action can work on many different types of books. This is called polymorphism. You can ask many different objects to perform the same action.

Before starting to an example on real world of automation, let's revise the concepts we told about:
- Object
- Class
- Inheritance
- Encapsulation
- Polymorphism

Because we are going to check if it is possible to apply them in automation systems design.

A multiple rack store system is a common structure. Mostly, two or more shuttles are used to put or take goods. FIFO can be achieved by this system, and sometimes one of the racks runs in reverse direction to make it possible to take out a good in the middle of the rack.
Well, I think this system is common, becase I have seen at least five and they were used for different purposes such as automatic storage and retrieval system or quality assurance test system.
Anyway, we are going to model such a system below:

Eight racks with two shuttles, one rack is working in reverse direction. The shuttle on the right is used for loading, and the other is used for unloading. 

It is possible to store up to 128 boxes in this storage area. 

We want to built a virtual model of the real world, we are going to start by finding out the objects in this system.

It is not too difficult, the first object is conveyor. Our conveyors are driven by a motor, and a conveyor can store two boxes. Each conveyor conducts the boxes forward if next conveyor is available:

Our second object is shuttle. There are two shuttles and each shuttle can give and take boxes in reverse or forward direction.

Our third object is a little bit hidden. Racks are also objects, and they consist of conveyors.

Now, let's focus on our objects capabilities. For example, each conveyor can conduct a box from one conveyor to the next one. Also, each conveyor take boxes.
Many PLC programmers use at least two output flags to give information to the next conveyors code:
1 - I am ready to give
2 - I am giving

and use at least two input flags to give information from previous conveyors code:
1 - I am ready to take
2 - I am taking

Logic is easy, if target conveyor is ready to take and source conveyor is ready to give, box should move to the next conveyor.

We can think about two more objects on the basic conveyor object: a transmitter and a receiver. Of course, these are not real objects, just functionalities but thinking them as seperate objects will be convenient for us.
It is obvious that, transmitter object has 'Transmit' method, and receiver object has 'Receive' method. By designing them as methods, we won't involve in handshaking between two conveyors, remember the encapsulation.

Most object oriented PC programming languages present a notation for objects and methods as follows:
Transmitter.Transmit()
Receiver.Receive()

And these two objects are belong to a conveyor object, so in programming notation, it also can be presented as:
Rack.Transmitter.Transmit()
Rack.Receiver.Receive()

If you realise an inconsistency or a bug in your logic, you do not need to code for all conveyors, just change the transmit or receive method and all objects using these methods will be get changed. Maintenance of object oriented code is easy.

And what about shuttles? Shuttles are also conveyors and also should have transmitter and receiver. So, to transfer a box from shuttle to a conveyor, we should be able to write as:
Shuttle.Transmitter.Transmit()
Rack.Receiver.Receive()

However, shutles have one more fuınctionality, they can move in Y direction to travel between racks, so we can think for a move method for shuttle:
Shuttle.MoveY()

Our another object is rack. A rack is made up of 8 conveyors. Rack can take boxes from shuttle and give boxes to another shuttle. It seems hat we can directly map the rearmost conveyors receive method as racks receive methods and map the farthermost conveyors transmit method as racks transmit method. Mapping is done once, and programmer can use it as:
Rack.Transmit()
without minding that it is actually:
FarthermostConveyor.Transmit()

Many experienced programmers realise one more object: Eight racks form another big object, the 'layer'. Programmers must anticipate that system may be upgraded to a multilayer stock system in next years.

And the final object is the system itself, having several methods such as:
System.Store()
System.Retrieve()

It would be nice to retrieve a box of chocolates just by executing a single command:
System.Retrieve("The yummy one")

Conclusions:
PLC programmers are working with objects for many years, each conveyor, machine, system is an object. Object oriented design and object oriented programming are different concepts.
In our example, we designed our system in object oriented approach but could not give example with rungs. Actually, object oriented PC programming languages present tools and facilities to implement an object oriented system as a code, however the code running at the back is not so different from procedural programming

For example, in object oriented way, you create a Shuttle class. Then you create a specific shuttle object, such as 'InputShuttle'.

You do it as:
____________
Class Shuttle
Method MoveY()
...
...
End Class


Dim InputShuttle As Shuttle
...


InputShuttle.MoveY
__________

And in procedural way, you write a function for moving any shuttle, and state the shuttle to be moved as a function parameter:
__________
Function MoveY(Shuttle As TShuttle)
...
End Function


Dim InputShuttle As Shuttle
...


MoveY(InputShuttle)
...
_____________

With this point of view, function blocks can be used in procedural way.

PLC software development environments and languages does not supply neccessary support for object oriented programming, however you can still design your system in abject oriented approach to recude the amount of code you wrote.

I hope, PLC vendors intruduce new functionalities to their development tools for supporting object oriented programming.

For the next post, I am planning to post something about PC stability. Then I am planning to post a case study, 'Power measurement test system - Beating the speed limits'