31. SOFTWARE ENGINEERING
31.1 INTRODUCTION
A careful, structured approach to designing software will cut the total development time, and result in a more reliable system.
31.1.1 Fail Safe Design
It is necessary to predict how systems will fail. Some of the common problems that will occur are listed below.
Component jams - An actuator or part becomes jammed. This can be detected by adding sensors for actuator positions and part presence.
Operator detected failure - Some unexpected failures will be detected by the operator. In those cases the operator must be able to shut down the machine easily.
Erroneous input - An input could be triggered unintentionally. This could include something falling against a start button.
Unsafe modes - Some systems need to be entered by the operators or maintenance crew. People detectors can be used to prevent operation while people are present.
Programming errors - A large program that is poorly written can behave erratically when an unanticipated input is encountered. This is also a problem with assumed startup conditions.
Sabotage - For various reasons, some individuals may try to damage a system. These problems can be minimized preventing access.
Random failure - Each component is prone to random failure. It is worth considering what would happen if any of these components were to fail.
Some design rules that will help improve the safety of a system are listed below.
· A fail-safe design - Programs should be designed so that they check for problems, and shut down in safe ways. Most PLC's also have imminent power failure sensors, use these whenever danger is present to shut down the system safely.
· Proper programming techniques and modular programming will help detect possible problems on paper instead of in operation.
· Modular well designed programs.
· Use predictable, non-configured programs.
· Make the program inaccessible to unauthorized persons.
· Check for system OK at start-up.
· Use PLC built in functions for error and failure detection.
· Provide clear and current documentation for maintenance and operators.
· Provide training for new users and engineers to reduce careless and uninformed mistakes.
31.2 DEBUGGING
Most engineers have taken a programming course where they learned to write a program and then debug it. Debugging involves running the program, testing it for errors, and then fixing them. Even for an experienced programmer it is common to spend more time debugging than writing software. For PLCs this is not acceptable! If you are running the program and it is operating irrationally it will often damage hardware. Also, if the error is not obvious, you should go back and reexamine the program design. When a program is debugged by trial and error, there are probably errors remaining in the logic, and the program is very hard to trust. Remember, a bug in a PLC program might kill somebody.
31.2.1 Troubleshooting
After a system is in operation it will eventually fail. When a failure occurs it is important to be able to identify and solve problems quickly. The following list of steps will help track down errors in a PLC system.
1. Look at the process and see if it is in a normal state. i.e. no jammed actuators, broken parts, etc. If there are visible problems, fix them and restart the process.
2. Look at the PLC to see which error lights are on. Each PLC vendor will provide documents that indicate which problems correspond to the error lights. Common error lights are given below. If any off the warning lights are on, look for electrical supply problems to the PLC.
HALT - something has stopped the CPU
RUN - the PLC thinks it is OK (and probably is)
ERROR - a physical problem has occurred with the PLC
3. Check indicator lights on I/O cards, see if they match the system. i.e., look at sensors that are on/off, and actuators on/off, check to see that the lights on the PLC I/O cards agree. If any of the light disagree with the physical reality, then interface electronics/mechanics need inspection.
4. Consult the manuals, or use software if available. If no obvious problems exist the problem is not simple, and requires a technically skilled approach.
5. If all else fails call the vendor (or the contractor) for help.
31.2.2 Forcing
Most PLCs will allow a user to force inputs and outputs. This means that they can be turned on, regardless of the physical inputs and program results. This can be convenient for debugging programs, and, it makes it easy to break and destroy things! When forces are used they can make the program perform erratically. They can also make outputs occur out of sequence. If there is a logic problem, then these don't help a programmer identify these problems.
Many companies will require extensive paperwork and permissions before forces can be used. I don't recommend forcing inputs or outputs, except in the most extreme circumstances.
31.3 PROCESS MODELING
There are many process modeling techniques, but only a few are suited to process control. The ANSI/ISA-S5.1-1984 Piping and Instrumentation Diagram (P&ID) standard provides good tools for documenting processes. The symbols used on the diagrams are shown in Figure 451 Symbols for Functions and Instruments. Note that the modifier used for the instruments can be applied to other discrete devices.
The process model is carefully labeled to indicate the function of each of the function on the diagram. Table 2 shows a list of the different instrumentation letter codes.
Table 3: ANSI/ISA-S5.1-1984 Instrumentation Symbols and Identification |
||
The line symbols also describe the type of flow. Figure 452 Flow Line Symbols and Types shows a few of the popular flow lines.
Figure 453 Sensor and Actuator Symbols and Types shows some of the more popular sensor and actuator symbols.
31.4 PROGRAMMING FOR LARGE SYSTEMS
Previous chapters have explored design techniques to solve large problems using techniques such as state diagrams and SFCs. Large systems may contain hundreds of those types of problems. This section will attempt to lay a philosophical approach that will help you approach these designs. The most important concepts are clarity and simplicity.
31.4.1 Developing a Program Structure
Understanding the process will simplify the controller design. When the system is only partially understood, or vaguely defined the development process becomes iterative. Programs will be developed, and modified until they are acceptable. When information and events are clearly understood the program design will become obvious. Questions that can help clarify the system include;
"What are the sequences of inputs and outputs?"
"Can a diagram of the system operation be drawn?"
"What information does the system need?"
"What information does the system produce?"
When possible a large controls problems should be broken down into smaller problems. This often happens when parts of the system operate independent of each other. This may also happen when operations occur in a fixed sequence. If this is the case the controls problem can be divided into the two smaller (and simpler) portions. The questions to ask are;
"Will these operations ever occur at the same time?"
"Will this operation happen regardless of other operations?"
"Is there a clear sequence of operations?"
"Is there a physical division in the process or machine?"
After examining the system the controller should be broken into operations. This can be done with a tree structure as shown in Figure 454 Functional Diagram for Press Control. This breaks control into smaller tasks that need to be executed. This technique is only used to divide the programming tasks into smaller sections that are distinct.
Each block in the functional diagram can be written as a separate subroutine. A higher level executive program will call these subroutines as needed. The executive program can also be broken into smaller parts. This keeps the main program more compact, and reduces the overall execution time. And, because the subroutines only run when they should, the change of unexpected operation is reduced. This is the method promoted by methods such as SFCs and FBDs.
Each functional program should be given its' own block of memory so that there are no conflicts with shared memory. System wide data or status information can be kept in common areas. Typical examples include a flag to indicate a certain product type, or a recipe oriented system.
Testing should be considered during software planning and writing. The best scenario is that the software is written in small pieces, and then each piece is tested. This is important in a large system. When a system is written as a single large piece of code, it becomes much more difficult to identify the source of errors.
The most disregarded statement involves documentation. All documentation should be written when the software is written. If the documentation can be written first, the software is usually more reliable and easier to write. Comments should be entered when ladder logic is entered. This often helps to clarify thoughts and expose careless errors. Documentation is essential on large projects where others are likely to maintain the system. Even if you maintain it, you are likely to forget what your original design intention was.
Some of the common pitfalls encountered by designers on large projects are listed below.
· Amateur designers rush through design to start work early, but details they missed take much longer to fix when they are half way implemented.
· Details are not planned out and the project becomes one huge complex task instead of groups of small simple tasks.
· Designers write one huge program, instead of smaller programs. This makes proof reading much harder, and not very enjoyable.
· Programmers sit at the keyboard and debug by trial and error. If a programmer is testing a program and an error occurs, there are two possible scenarios. First, the programmer knows what the problem is, and can fix it immediately. Second, the programmer only has a vague idea, and often makes no progress doing trial-and-error debugging. If trial-and-error programming is going on the program is not understood, and it should be fixed through replanning.
· Small details are left to be completed later. These are sometimes left undone, and lead to failures in operation.
· The design is not frozen, and small refinements and add-ons take significant amounts of time, and often lead to major design changes.
· The designers use unprofessional approaches. They tend to follow poor designs, against the advice of their colleagues. This is often because the design is their child
· Designers get a good dose of the not invented here syndrome. Basically, if we didn't develop it, it must not be any good.
· Limited knowledge will cause problems. The saying goes "If the only tool you know how to use is a hammer every problem looks like a nail."
· Biting off more than you can chew. some projects are overly ambitious. Avoid adding wild extras, and just meet the needs of the project. Sometimes an unnecessary extra can take more time than the rest of the project.
31.4.2 Program Verification and Simulation
After a program has been written it is important to verify that it works as intended, before it is used in production. In a simple application this might involve running the program on the machine, and looking for improper operation. In a complex application this approach is not suitable. A good approach to software development involves the following steps in approximate order:
1. Structured design - design and write the software to meet a clear set of objectives.
2. Modular testing - small segments of the program can be written, and then tested individually. It is much easier to debug and verify the operation of a small program.
3. Code review - review the code modules for compliance to the design. This should be done by others, but at least you should review your own code.
4. Modular building - the software modules can then be added one at a time, and the system tested again. Any problems that arise can then be attributed to interactions with the new module.
5. Design confirmation - verify that the system works as the design requires.
6. Error proofing - the system can be tested by trying expected and unexpected failures. When doing this testing, irrational things should also be considered. This might include unplugging sensors, jamming actuators, operator errors, etc.
7. Burn-in - a test that last a long period of time. Some errors won't appear until a machine has run for a few thousand cycles, or over a period of days.
Program testing can be done on machines, but this is not always possible or desireable. In these cases simulators allow the programs to be tested without the actual machine. The use of a simulator typically follows the basic steps below.
1. The machine inputs and outputs are identified.
2. A basic model of the system is developed in terms of the inputs and outputs. This might include items such as when sensor changes are expected, what effects actuators should have, and expected operator inputs.
3. A system simulator is constructed with some combination of specialized software and hardware.
4. The system is verified for the expect operation of the system.
5. The system is then used for testing software and verifying the operation.
A detailed description of simulator usage is available [Kinner, 1992].
31.5 DOCUMENTATION
Poor documentation is a common complaint lodged against control system designers. Good documentation is developed as a project progresses. Many engineers will leave the documentation to the end of a project as an afterthought. But, by that point many of the details have been forgotten. So, it takes longer to recall the details of the work, and the report is always lacking.
A set of PLC design forms are given in Figure 455 Design Cover Page to Figure 461 Ladder Logic Page. These can be used before, during and after a controls project. These forms can then be kept in design or maintenance offices so that others can get easy access and make updates at the controller is changed. Figure 455 Design Cover Page shows a design cover page. This should be completed with information such as a unique project name, contact person, and controller type. The list of changes below help to track design, redesign and maintenance that has been done to the machine. This cover sheet acts as a quick overview on the history of the machine. Figure 456 Project Note Page to Figure 458 Project Diagramming and Notes Page show sheets that allow free form planning of the design. Figure 459 IO Planning Page shows a sheet for planning the input and output memory locations. Figure 460 Internal Memory Locations Page shows a sheet for planning internal memory locations, and finally Figure 461 Ladder Logic Page shows a sheet for planning the ladder logic. The sheets should be used in the order they are given, but they do not all need to be used. When the system has been built and tested, a copy of the working ladder logic should be attached to the end of the bundle of pages.
These design sheets are provided as examples. PLC vendors often supply similar sheets. Many companies also have their own internal design documentation procedures. If you are in a company without standardized design formats, you should consider implementing such a system.
31.6 COMMISIONING
When a new machine is being prepared for production, or has been delivered by a supplier, it is normal to go through a set of commissioning procedures. Some typical steps are listed below.
· verify that the machine meets internal and external safety codes
- worker safety codes (e.g., OSHA)
· determine if all components are present
· physically located the machine
· connect to adjacent machines
· connect water, air and other required services
· high potential and ground fault tests
· verify sensor inputs to the PLC
· start the machine and test the emergency stops
· test for basic functionality
· run the machine and make adjustments to produce product
· collect process capability data
· determine required maintenance procedures
6. Contract/specification verification
· review the contact requirements and check off individually on each one
· review the specification requirements and check off each one individually
· request that any non-compliant requirements are corrected
· start the process in the production environment and begin normal use
31.7 SAFETY
Previous chapters have discussed safety as an inherent part of the design process - AS IT MUST BE. These include elements such as making stops normally closed, starts normally open, systems return to safe inherently, programs that are predictable, etc. There are a variety of systems for evaluating and managing safety issues from a range of groups including NASA, DOD, and many more.
31.7.1 IEC 61508/61511 safety standards
These standards cover electrical, electronic, and programmable electronic systems. Three categories of software languages covered by the standard
FPL (Fixed Programming Language) - a very limited approach to programming. For example the system is programmed by setting parameters.
LVL (Limited Variability Language) - a language with a strict programming model, such as ladder logic.
FVL (Full Variability Language) - a language that gives full access to a systems, such as C.
Dangers can be estimated using a Safety Integrity Level (SIL) - the safety requirements for a function in a system. These estimates of failure can be calculated using individual component reliability, historical data, and some careful consideration. Typical probabilities of failure by type of system are given below.
High Demand or continuous mode:
System safety levels are defined with one of the three categories below.
SIF (Safety Instrumented Function) - The SIL for each function is chosen to ensure an overall system functionality.
SIS (Safety Instrumented System) - A combined system with one or more logic processors.
SFF (Safe Failure Fraction) - the ratio of safe and dangerous detected failures to the total failures.
To calculate the SFF and/or overall system failure probability there is a need to refer to the relevant statistical theory. Some of the common approaches are listed.
- do an FMEA for each system component in the system
- classify failure modes as safe or dangerous
- calculate the probabilities of safe/dangerous failures (S/D [0, 1])
- estimate the fraction of the failures that can be detected (F [0, 1])
31.8 LEAN MANUFACTURING
Lean manufacturing focuses on the elimination of waste, formalizing a common source approach to machine design. Some general concepts to use when designing lean machines include,
- setups should be minimized or eliminated
- product changeovers should be minimized or eliminated
- make the tool fit the job, not the other way. If necessary, design a new tool
- design the machine be faster than the needed cycle time to allow flexibility and excess capacity - this does seem contradictory, but it allows better use of other resources. For example, if a worker takes a bathroom break, the production can continue with fewer workers.
- allow batches with a minimum capacity of one.
- people are part of the process and should integrate smoothly - the motions or workers are often described as dance like.
- eliminate wasted steps, all should go into making the part
- work should flow smoothly to avoid wasted motion
- do not waste motion by spacing out machines
- design "decouplers" to allow operations to happen independently.
- eliminate material waste that does not go into the product
- design the product so that it is easy to manufacture
- use methods that are obvious, so that anybody can understand - this makes workers portable and able to easily cover for others.
- design tools to reduce the needs for guards.
To achieve these principles the complexity of a machine may be increased to decrease the manual labor and setup issues. In lean manufacturing the ideal batch size is one with no switchover time.
31.9 REFERENCES
Eberhard, A, "Safety in Programmable Applications", Automation World, Nov., 2004.
Kenner, R. H., "The Use of Simulation Within a PLC to Improve Program Development and Testing", Proceedings of the First Automation Fair, Philadelphia, 1990.
McCrea-Steele, R., "Proven-in-Use: Making the right choices for process safety", Hotlinks, Invensys, Summer 2003.
Paques, Joseph-Jean, "Basic Safety Rules for Using Programmable Controllers", ISA Transactions, Vol. 29, No. 2, 1990.
31.10 SUMMARY
· Debugging and forcing are signs of a poorly written program.
· Process models can be used to completely describe a process.
· When programming large systems, it is important to subdivide the project into smaller parts.
· Documentation should be done at all phases of the project.
31.11 PRACTICE PROBLEMS
(Note: Problem solutions are available at http://sites.google.com/site/automatedmanufacturingsystems/)
1. List 5 advantages of using structured design and documentation techniques.
31.12 ASSIGNMENT PROBLEMS
1. What documentation is requires for a ladder logic based controller? Are comments important? Why?
2. When should inputs and outputs be assigned when planning a control system?
3. Discuss when I/O placement and wiring documentation should be updated?
4. Should you use output forces?
5. Find web addresses for 10 PLC vendors. Investigate their web sites to determine how they would be as suppliers.