I asked this previously on comp.os.vxworks. I am not really interested in vxWorks specifically, but how would one partition software for a control systems. Ie, what kind of OS constructs would you use?
I gave an example of a CPU that would control several lines filling pop bottles. Specifically the speed of the conveyor and a bottle "grabber" would be the controls. An optical sensor a fixed distance away from the "grabber" and a line jam/bottle spill detector would be present. There would be a refill light and buzzer and a sensor to detect a "low" number of bottle caps in a chute as well as no bottle caps.
I was interested in how to structure this. Ie, it was suggested to use separate tasks for input, control and output. I am particularly interested in how to handle "exception" items like no bottle caps or line jam. I would expect to stop the motor and all motion when one occurs; ie, they generate asynchronous signals to stop motion.
Some faults like empty cap chute might slow the line gradually so that the bottles don't spill from an instantaneous stop that might occur if power was cut.
As there are multiple lines, you just need to use a structure instead of any global variables (or use C++) to accomplish this. It would make things easier if each line had its own task(s).
Certainly an interesting question. It will certainly illicit quite a few different styles and answers, probably quite a bit of discussion about whether method A or B is better than Method C. Well, my view is below the rest of this and I look forward to seeing the other responses too. Shame I will be away from the PC for the next 30 hours. Ah well, I'll catch up Saturday night.
Whatever way you structure your system, my view is that the structure of the solution space should be a reasonably good model for the structure of the problem space, with good correlation. It appears that, through maintenance mostly, many systems will be adapted to have a good correlation between the problem and solution spaces (search for AMUSE, a study in architectural similarities in software, if you want to know more about this topic).
I tend to look at the overall layout of the plant that is to be controlled and work out how many actuators there are likely to be in place amongst the plant to ensure proper control over the whole process. Then it is a matter of deciding what measurements are required in order to determine what is happening in the process. I will, at that stage group the actuators and sensors so that I have clearly identified the control goups that are required. I will then usually assign a processor per control group (which is usually also a processor per actuator). This is the first step in simplifiying the whole control software.
As we are now dealing with many processors, it becomes necessary to determine the information flows for the system and ensure that all the information whose scope reaches beyond one processor is properly communicated across or up the system.
How you structure the software for each processor can then be sketched out to provide a framework for notions such as tasks, communication ports, interlocks and safety controls. Naturally, when you begin the design of a control system you will begin to identify hazards associated with building, testing, operating and maintaining the equipment and will have built a risk assessment for the whole system (but you all knew that anyway).
I usually do an analysis of the tasks that are to be performed by the processor and break those down so that I know what facets should be in interrupts, which confined to a task-thread and which facets should be in the slower back-drop/scheduler portion. Sometimes there is the traditional input/process/output algorithmic approach, other times you may adopt a state-machine approach. Occassionally you may even look to fuzzy-logic methods. Each has its own benefits and problems and you have to determine the trade-offs you will accept.
For the bottling lines I would certainly look at several processors interlinked with single-bit logic (key markers) and may utilise a serial communcications bus to enable the adjustment of parameter variables (speed of operation, fill-pressure allowances, fill-times etc) and collection of logged counts (faults and bottles handled since last check etc)..
Many, I know, will propose doing the whole job on a single processor. They think that dealing with lots of little processors in a job is getting complicated. I consider that using more silicon can often simplify the development. Instead of wrestling with ensuring timing between competing parts of the system I have eliminated a great deal of the complications and often eliminated the need for an expensive OS as well.
Typically with modern practises, (based on the S88 standard and much simplified) Control Module Level: Modules for each Device (eg Motor) , these modules handling Auto and Manual operation,the IO, and being written as a re-usable function so that each motor is using the same code. Equipment Module Level: Module that can set the group of Control Modules that are contained in the Equipment Module to states according to the required state for the EM. Also providing Exception handling. Phase Level: Modules for each Phase - sequential function that drive the EM to states, typically using SFC/Grafcet For more details take a look at
formatting link
oriented around the requirements rather than the code, the document presents a suitable modular structure.) Francis
I'd be careful about using separate OS tasks, if that's what you mean.
On the other hand using an object-oriented code structure that will let you have a generic motor controller code that can be divorced from the particular interface to the motor itself is quite useful.
I generally structure this with one OS task per motor, with that task handling all input, motor control and output. In C++ the code will be split into several classes, with a motor control base class, a motor interface abstract base class, and the correct derived class for the motor interface at hand.
The higher-level thinking (like what to do if you run out of bottle caps) is handled in a separate executive task which sends commands to the various motion control tasks. I can easily see that in your case you may have more than one level of executive, e.g. one that sets the trajectories for the motors, and another higher level that determines which of a number of predetermined trajectories may be chosen, depending on circumstances.
Given your multiple line idea I would go for one controller (or panel) for each line, each one of which may have multiple processors or PLC's. That will keep your design more modular and give you more flexibility for adding, removing, and changing lines.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.