coder . cl

As you know I am working on an Industrial Control System — ICS/DCS to be more specific — and this system requires a task schedule to activate some pumps with a very strict calendar, monitoring the amount of liquid that has been passed through the valve, and it should allow manual operations, interrupting the automatic operation of that node on the plant. This seems to be difficult to implement, as I wrote in past posts, we are using a priority queue that contains task requests, where every priority is entirely dynamic, and dependent on the state of the current state machine that is being executed according to the operation request.

Defining state machines is not so hard as it appears. Initially you can build constructs that can help on building automata processing much friendly than using plain code. Starting from the idea that you can place your state machine inside data structures allowing friendly editing without modifying the processing code. Any stateful processing can be migrated to state machines. As any automata can be represented in a state diagram and then it can be migrated to plain data structures. Even if you are using a purely functional programming language, you can place a stateful processing data structure to be processed as automata.

Graphical objects in ProView are providing two types animations and behavior attributes, where both can be highly customized. Dynamics are those animations related on how the object operates with the environment — mouse and keyboard — and the logical plant nodes. At the other side, actions are those XTT commands triggered with the user interaction. So, for example we have the Electric > ControlSwitch sub-graph, which has the action DigShift, but we can change the DigShift action to ToggleDig, allowing a digital input switching between True and False, and preserve the rotate animation which is inherited from its definition.

As you know I am working on a ProView project. It has a logical and physical distinction between plant and station nodes. Physical nodes are mainly controlled by logical nodes, including user defined applications written in C, C++ or Java. On this case we are using C and C++, C for low level ProView calls and C++ to create a nice object oriented interface. A very good approach is found on ProView General Data Handler or GDH API, where you can have access to the full node hierarchy using GDH calls. This allows managing nodes in all levels, even if you want to create new nodes in run-time. This is very nice, so I have defined a C++ class device to manage each device automatically and due to the algorithm complexity we cannot use PLC programming.

Understanding the I/O layers on ProView is a must. If you understand the I/O layers, you will be able to configure channels and signals grouped in classes allowing a very good usage and abstraction of the devices that are being examined and manipulated from ProView. For example a Profibus device can have 8 digital input channels for its status, but they should be grouped a custom class using an array of digital channels with Bit8 as data representation, so they are used as object attributes rather than separate channels, if you do not configure the proper class, you will be wasting your time configuring separate channels for each device, leading to some mistakes. Just imagine that you want to configure 50 devices with the same number of channels for its status, you will need to configure 50 times each channel. So, you really need to know about the I/O layering on ProView.

I am currently working on a ICS/DCS system using ProView. The project is cool, very interesting, where I must implement some nodes on the DCS system, as usual it has three main types of nodes where I must implement two of them: the controlling station and the processing station, there are more nodes to be implemented in the future, like reporting nodes and storage nodes. I was working with the controlling station and I was impressed with the abstraction layer, where you can bind the processing station objects into the HMI objects directly. This is really nice, and due to the nature of the used protocols, like Modbus, RP, Profibus and similar ones, we are not able to use a Web Interface.

I started using ProView. This is a process control and automation system with a FOSS license, which makes it a good approach for building some interesting projects. It is nice, you can define from single controlled nodes to complete processing stations and HMIs controlling each node. You can use simple PLC programs for the defined hardware and devices, or you can use C, C++ or Java — but Java is not so useful due to real-time application requirements — applications if the station processing and control requires more complex algorithms, which cannot be handled using PLC programs. That is the case of my current project, I am building an application that acts as PLC program which will implement some complex algorithms.