Projects


Project I. - Automation of a virtual production plant

name

Abstract

In this project a virtual production plant created in Factory IO was automated using the Siemens TIA Portal PLC programming engineering solution. The main goal was to create a library of function blocks, which could be used to automate any device layout deviseable in Factory IO, not just the one presented in this project. In order to achieve this and to create and easy to understand architecture, object-oriented software design principles have been employed.

Software tools used

The three main software tools used for creating this project were Factory IO, Siemens TIA Portal Basic v16, and Capella.

Factory IO was chosen as a platform for creating the virtual plant because it presents a wide variety of common factory devices, it is easy to create any number of plant layouts with them, requires minimum learning effort to start using, and it can interface with a number of well known automation solutions.

TIA Portal Basic is a good choice when trying to learn as much as possible about real-world automation solutions for a reasonable price, as it provides every tool required for it, like PLC programming environment, an HMI engineering environment and a simulator for both PLC and HMI, which makes costly physical PLC and related hardware unnecessary. Although the basic version doesn’t support some of the advanced features of the Pro version (i.e. break points, software units, references, GRAPH language, PID execution on PLCSIM, higher performance hardware, etc.), it is still quite possible to author quite complex control software, but the code and testing might become a bit more complicated.

Capella was chosen a modeling tool and language, as it is more general than UML, simpler to use than SysML and this language comes with a development method and tool specifically designed for it. Although the documentation and learning material available for it was found to be needing some improvement, the tool proved to be usable to model not just the software, but the whole system as well, without any prior knowledge about systems modeling.

Discussion

As the most important specifics of the project and control software have been discussed in the following videos, they will not be repeated here. Please watch the videos before continuing.





Remarks

This section is devoted to some of the observations that were made during the creation of this project, which are presented here in no particular order.

Factory IO

  • Not being able to adjust the weight of the boxes results in the scattering of them once palletized and moved around.
  • The amount of allowed analog IO is fairly limited and easy to exhaust.

TIA Portal V16
The following few points demonstrate some of TIA Portal’s weaknesses, which if fixed, could improve development experience:

  • Not being able to monitor function parameter contents at the declaration table during runtime: without being able to see right at the declaration what information gets in/out of the F/FB, it is much harder to debug the program, especially when UDTs as IO data types are involved. Needing to open up the containing DB in case of UDTs or the calling environment of the function in case of built-in types seems to be cumbersome.
  • Not being able to initialize DB variables with user defined global constants: At the moment only a literal is allowed to be used to initialize DB variables. Being able to use mentioned constants would add further flexibility to development.
  • Lack of a single-cycle execution mode: Being able to execute the program cycle by cycle would be helpful during debugging sessions, especially when testing state machines.
  • Lack of a standard output or equivalent for testing: At the moment, there is no way to print the contents of a variable out to a standard output, which makes the testing of loops harder than it should be. A watchtable with a historical output at the bottom (for all selected variables defined in the table) would be really helpful in such cases.
  • Lack of assert-like functionality for testing: Being able to define assert-like functions that would not be compiled into the actual control program would allow testing library functions against predefined inputs and known outputs.
  • WinCC Basic (and Basic HMI panels) not supporting UDTs: it discourages people from using UDTs and/or invites the usage of structs (which are to be avoided, as per the Siemens docs). Basic panels supporting structs but not UDTs seems a bit awkward.
  • Changing the call environment of a function could be a bit more polished: At the moment the clearest way to do it is opening the function from the call environment. Being able to do it with a folder-tree like selection window would be nice.

Capella

  • Keeping the amount of diagrams at the minimum during the development of the model reduces the amount of time required to finish the model considerably, as only a small amount of diagrams will need to be maintained after changes to the model have been made. Since repairing diagrams all the time requires a considerable amount of time, creating only the master diagrams initially seems to be a good approach. Diagrams applicable for presentation and documentation are better created only when the model (layer) reached sufficient maturity.
  • The documentation could use more polishing.