Documentation (work in progress)

Full access to documentation, the basic foundation for openess.

FreeDCS is open wich means that you can see all the documentation and source code to see how it's done. In this section you will find links to all the documentation about the project. Ranging from the documents about the system design to network layouts and examples.

Network Layout:

The overall system could be composed of a single i386 PC running the FreeDCS software and some Field I/O (digital or analog at first) modules that interface with a machine or process to control.

This is a simple system, but what happens if i want to control a huge mill with more than 50.000 I/O's ? Well, thats why Distributed Control Systems (DCS) were invented, to grow when it's needed without been a complete and complicated mess.

You will be able to use FreeDCS also to control a huge mill if needed!. Just separate your mill in small processes and use enough controllers and field I/O modules to do it. The controllers will comunicate through Ethernet to pass all the data that is needed and gaining controll of your process.

We can see a medium sized process network in this diagram:

Medium network layout

In the diagram you see that the network is divided by switches in 3 areas (I'm not taking into account the office network), 2 process areas and a Engineering Network (I'll expain this shortly). It is likely that devices in each process area network will have a higher data exchange rate than 2 devices each one in different areas. That's why we put a switch in each area, to enable high throughput of data. All the areas communicate through the main switch wich each other. It will be possible also to use a redundant Ethernet network to be safe if you wish.

Let's explain now each component that appears in the drawing:

Engineering Station:

All the Engineering Stations (ENST) will be (preferably) in the same network because there will be traffic between them that it's not needed in the process network (configuration database replication). The working model is that you configure your hardware, create your process control logic and displays in the Engineering Station and then send the compiled files to the devices affected and thats all. Then you could use the Eng.Stat. to see the control programs running inside the controller and force the value you want (for debugging or troubleshooting purposes).

Operator Station:

Operators will manage your process (or industrial machines) using the Operator Station (OPST) device. It's (as expected) a i386 compatible PC running FreeDCS software that communicates with the necessary controllers to gather all the input and processed data, and then according to the operator instructions open or close a valve, run or stop a motor, etc. All the proces will be showed to the operator through a graphic interface with icons representing Tanks, Pumps, Valves, etc. With this approach you get an overall view of your process very quick.

History Server:

The History Server (HSER) will be used in the future to capture process data for longer time. The server will run Linux but as with the controller, you will not notice it because it will be a black box capable of storing data and retrieving it to the OPST when asked. It will be configured through the ENST as usual.

Controller:

The controller (CON) is a very important part in the system, but it's as simple as a i386 compatible PC running a small version of Linux. But lets be clear here, you DON'T need to know anything about Linux to install, configure or use FreeDCS, Linux is in the bottom doing his work and you will not even notice it. The controller allows you to run your controll alghoritms (or program) in parallel as if you were running multiple PLC programs at the same time. For example you can have a control program to control a washing machine and another to control the temperature inside a room in your home and both programs will run at the same time. Each control program is a separate task in the controller, meaning that if a control program is hanged, the other ones will continue running normally.

Processes inside the controller:

Processes map. (work in progress)

Field I/O Modules:

Last but not least, Field I/O modules bring the signals from the instruments in the field to the digital domain inside the controller. The Field I/O modules are attached to the controller through a redundant serial network. It's likely at first that the speed of the serial bus will be 115kbps, that's enough to update the inputs at a reasonable rate (under a second) and enable us to use the serial port in a PC. The I/O modules will have microcontrollers to handle the data and comms and in case of failure the microcontroller can force a safe (presetted) value to the output if needed.