M
I have 13 years experience working in the Controls Industry. I've programmed PLC's, written Modbus Drivers, and designed Plant Scale (we're talking 100K tags + - large plants) information systems for Plant Instrumentation Information Management.
My experience working in the Controls field was that insufficient resources were made available to do a proper job. The expectation was for robustness, with never enough time or money (read corporate greed). I worked in Consulting, primarily in the Irrigation Industry (6 years), and the Oil and Gas Industry (7 years - Calgary).
Before anybody starts thinking about the scope of features that the PLC based controller should have, I would strongly suggest that everybody first stand back and look at the big picture.
1. The big picture is: A control system is a piece of the information flow. The key element of this information flow is first: proper definition and configuration management of all elements that participate in the generation and distribution of control system information (i.e., identification, registration and version(configuration) management). Call it the equivalent of Active Directory (Microsnot), or Novell Directory Service (NDS), with version control. This includes end devices, cabinets, wires, cables, bundles, barriers, controllers, network configurations, etc. You name it.
Creating a Plant Control System ultimately means being able to track all changes in the definition (state) of that system throughout its life. IF you don't consider this up front, you're wasting your time.
2. Interface Definition is all about deciding the approach to take in interfacing with other systems. Linux goes out of its way to be friendly with everybody else. The LinuxPLC must do likewise. What does playing friendly really mean, in the case of tieing together disparate control systems, communication protocols, and physical implementations?
3. Writing C code right off the bat is waste of time, IMHO. If you want to solve the big problem, then programming at a low level is not likely to facilitate an effective solution. Architecture and Design must occur first, if success is to be achieved.
It has been my dream to design and build a Generic Device Registry that can be used to manage the information for all components that comprise the Plant Information System. This Generic Definition would effectively become the standard, akin to TCP/IP, for Automation Solutions. It would be both a mechanism for facilating the definition and version management of the Plant Control System Database, and would also define the architecture of the system that uses this information.
I would be really interested in contributing to this project.
thx
My experience working in the Controls field was that insufficient resources were made available to do a proper job. The expectation was for robustness, with never enough time or money (read corporate greed). I worked in Consulting, primarily in the Irrigation Industry (6 years), and the Oil and Gas Industry (7 years - Calgary).
Before anybody starts thinking about the scope of features that the PLC based controller should have, I would strongly suggest that everybody first stand back and look at the big picture.
1. The big picture is: A control system is a piece of the information flow. The key element of this information flow is first: proper definition and configuration management of all elements that participate in the generation and distribution of control system information (i.e., identification, registration and version(configuration) management). Call it the equivalent of Active Directory (Microsnot), or Novell Directory Service (NDS), with version control. This includes end devices, cabinets, wires, cables, bundles, barriers, controllers, network configurations, etc. You name it.
Creating a Plant Control System ultimately means being able to track all changes in the definition (state) of that system throughout its life. IF you don't consider this up front, you're wasting your time.
2. Interface Definition is all about deciding the approach to take in interfacing with other systems. Linux goes out of its way to be friendly with everybody else. The LinuxPLC must do likewise. What does playing friendly really mean, in the case of tieing together disparate control systems, communication protocols, and physical implementations?
3. Writing C code right off the bat is waste of time, IMHO. If you want to solve the big problem, then programming at a low level is not likely to facilitate an effective solution. Architecture and Design must occur first, if success is to be achieved.
It has been my dream to design and build a Generic Device Registry that can be used to manage the information for all components that comprise the Plant Information System. This Generic Definition would effectively become the standard, akin to TCP/IP, for Automation Solutions. It would be both a mechanism for facilating the definition and version management of the Plant Control System Database, and would also define the architecture of the system that uses this information.
I would be really interested in contributing to this project.
thx
