B
My experience with getting contractors to write functional specs has been quite varied - from the small back-yard merchant who refused to put anything at all on paper because "he had put a lot of time and effort into getting it working and he wasn't going to give us all that information so we could use it on the next job", through a firm with acceptable but grammatically awful documents that could not be revised because it involved the whole company in a review process, to a guy would had never done one before but once we explained what was wanted produced a beautiful one in about 5 days.
The IEE has some material I have referenced in specifications - my copy of "Guidelines for the documentation of computer software for real time and interactive systems" ISBN 0 86341 233 5 dates from 1990. It can relatively easily be extended to cover hardware and field equipment as well. They also have a "Software quality assurance model procedures" ISBN 0 86341 230 0.
The operational words for a functional spec, according to the UK Health & Safety Executive, are "complete, concise, and unambiguous". I have used what I call an "operational cycle" approach to try and handle the "complete" part -
Define the various acceptable operational states of the system, starting from power down, and list all associated conditions of driven or activated
machinery.
Starting from power down, trace all the acceptable operational paths through the different states. For each transition from one state to another, define the events that will initiate the transition.
Look at each state and define the expected (or unexpected) faults - see earlier posting. Use this to decide how the faults can be detected and how they will be handled. Add the states arising during fault handling to the overall list.
Now comes the fun part. Starting at the beginning, trace every possible path through the various states that may occur in actual operation. This will involve complete loops from "Standby" or "Off" through start-up, operation, normal and abnormal shutdown, back to "Standby". Details of this actual sequence don't matter - the important thing is that the condition of the plant, considered as a whole, must be the same for any state regardless of how it is arrived at. So if a motor is started as part of the cycle, it must be stopped somewhere else: if an actuator is extended, it must be retracted.
Usually, the main route through the operational cycle is pretty well defined by what you want the plant to do, and will not give many problems. My experience has been that the fault handling parts of the system are poorly defined by the mechanical or process people, and have the most variation - after all there is usually only one way for the thing to work properly, but an infinite number of ways for it to go off the rails. The controls system designer usually has to come up with a lot of answers on the fault handling side.
Strangely enough, this starts to look remarkably like a Sequential Function Chart if you do it graphically!
It can help with developing the operator interface as well. Any operator actions will be defined as events that will initiate transitions between states, and each action must be based on relevant process information. Group all operator actions that are acceptable in a given state and all the required information needed for those actions, and you have a good guide as to what should be displayed on a screen page while the plant is in that state.
I've used this approach on a fairly complex GT cogeneration project where 2 GTs were feeding exhaust gas to a single auxiliary-fired Waste Heat Boiler. There were 16 possible states with each GT having its own bypass damper and stack, and associated dampers on the boiler. It greatly helped in the analysis process. I haven't had a lot to do with manufacturing processes, but what I have had would suggest that each element of a process train may possibly be treatable as a separate entity to try and keep the system simple.
One weapon I have used is to pick on any safety-related functions the machine may have, and use these as a tool to get the project management to take action. There is usually some (even if only peripheral) safety activity, and the threat of not complying with OSH requirements can work wonders if needed. We have a delightfully vague clause in the NZ Health & Safety in Employment Regulations to the effect that a designer is responsible for ensuring that the design is safe, and for providing all necessary documentation to manufacturers, suppliers and users so that it can be built, installed, commissioned, operated maintained, etc safely. Managers (especially of the project variety) may often not want to make a lot of fuss over what to them appears to be fairly insignificant, but the dreaded "S*$@&y" word usually gets things moving. IEC61508 is a bit too vague to give a useful handle, but IEC 61511 may be better, being more focused on process industries. I don't know how far it goes towards meeting the needs of the manufacturing automation industry.
Cheers,
Bruce.
The IEE has some material I have referenced in specifications - my copy of "Guidelines for the documentation of computer software for real time and interactive systems" ISBN 0 86341 233 5 dates from 1990. It can relatively easily be extended to cover hardware and field equipment as well. They also have a "Software quality assurance model procedures" ISBN 0 86341 230 0.
The operational words for a functional spec, according to the UK Health & Safety Executive, are "complete, concise, and unambiguous". I have used what I call an "operational cycle" approach to try and handle the "complete" part -
Define the various acceptable operational states of the system, starting from power down, and list all associated conditions of driven or activated
machinery.
Starting from power down, trace all the acceptable operational paths through the different states. For each transition from one state to another, define the events that will initiate the transition.
Look at each state and define the expected (or unexpected) faults - see earlier posting. Use this to decide how the faults can be detected and how they will be handled. Add the states arising during fault handling to the overall list.
Now comes the fun part. Starting at the beginning, trace every possible path through the various states that may occur in actual operation. This will involve complete loops from "Standby" or "Off" through start-up, operation, normal and abnormal shutdown, back to "Standby". Details of this actual sequence don't matter - the important thing is that the condition of the plant, considered as a whole, must be the same for any state regardless of how it is arrived at. So if a motor is started as part of the cycle, it must be stopped somewhere else: if an actuator is extended, it must be retracted.
Usually, the main route through the operational cycle is pretty well defined by what you want the plant to do, and will not give many problems. My experience has been that the fault handling parts of the system are poorly defined by the mechanical or process people, and have the most variation - after all there is usually only one way for the thing to work properly, but an infinite number of ways for it to go off the rails. The controls system designer usually has to come up with a lot of answers on the fault handling side.
Strangely enough, this starts to look remarkably like a Sequential Function Chart if you do it graphically!
It can help with developing the operator interface as well. Any operator actions will be defined as events that will initiate transitions between states, and each action must be based on relevant process information. Group all operator actions that are acceptable in a given state and all the required information needed for those actions, and you have a good guide as to what should be displayed on a screen page while the plant is in that state.
I've used this approach on a fairly complex GT cogeneration project where 2 GTs were feeding exhaust gas to a single auxiliary-fired Waste Heat Boiler. There were 16 possible states with each GT having its own bypass damper and stack, and associated dampers on the boiler. It greatly helped in the analysis process. I haven't had a lot to do with manufacturing processes, but what I have had would suggest that each element of a process train may possibly be treatable as a separate entity to try and keep the system simple.
One weapon I have used is to pick on any safety-related functions the machine may have, and use these as a tool to get the project management to take action. There is usually some (even if only peripheral) safety activity, and the threat of not complying with OSH requirements can work wonders if needed. We have a delightfully vague clause in the NZ Health & Safety in Employment Regulations to the effect that a designer is responsible for ensuring that the design is safe, and for providing all necessary documentation to manufacturers, suppliers and users so that it can be built, installed, commissioned, operated maintained, etc safely. Managers (especially of the project variety) may often not want to make a lot of fuss over what to them appears to be fairly insignificant, but the dreaded "S*$@&y" word usually gets things moving. IEC61508 is a bit too vague to give a useful handle, but IEC 61511 may be better, being more focused on process industries. I don't know how far it goes towards meeting the needs of the manufacturing automation industry.
Cheers,
Bruce.