Managing the invisible assets
Introducing a new process into your plant requires managing the software - not just the hardware - when it comes to PLCs.
The Programmable Controller (PLC) is the most vital control element in the manufacturing environment, yet the development and procurement of PLC programming services is ad hoc, often resulting in efficiency and maintenance problems. Those problems contribute to poor overall equipment effectiveness (OEE) figures and a resultant financial losses.
Hardware assets tend to be fairly obvious to a company, but software assets can be neglected simply because they are invisible. And yet software assets control the machines and processes. The support documentation for those assets attests to the quality of the PLC program development process and is a useful tool for solving hardware and software maintenance problems. Anybody responsible for a plant's software systems would do well to look at the PLC documentation, to check how detailed it is and whether it contributes positively to the maintenance function.
There are also other important questions to ask. For example, how many discrete machines in the plant are PLC-controlled and is the PLC source code for those machines accessible? This will furnish maintenance and engineering staff with the resources to change parameters or carry out software maintenance.
When procuring discrete machines with embedded PLCs, ensure that the PLC hardware and software is audited. It is as well to be forewarned whether a new acquisition is IEC 6-1134 compliant, or if it is an 'exotic' system that can only be maintained by the vendor. The introduction of a new process into a plant - and the contracting out of the PLC control element - requires multiple skills, including accurate detailing of the requirements of the new system and the appointment of a vendor.
In PLC program development, as in any software development, a disciplined and structured approach is required. There is considerable evidence of inadequate software design, and this is particularly important to industrial automation software project development.
The failure to adhere to basic software design criteria has resulted in major failures in projects in the public sector. The Royal Academy of Engineering cites losses of approximately £22bn for UK projects, £75bn for projects in the US and £70bn wasted in the European Union. The Irish e-voting system never really got started and has cost approximately £30m. Reports on software failures cite specific reasons for those, among them being:
- poor management;
- inadequate training;
- inadequate IT experience by senior managers;
- inadequate program structure;
- inadequate documentation.
Anecdotal evidence and at least one recent study of PLC program development revealed startling deficiencies. Most industries have no formal procedures for PLC program development or procurement, which is evident in the low levels of support documentation. Poor documentation results in maintenance problems that, in turn, result in increased machine downtime. Addressing those issues requires a structured PLC program design methodology.
The diagram on p52 outlines the stages of program development, which, as can be seen, is an iterative system, such that each stage may be revisited and possibly modified as a result of new information emerging from other stages.
Requirement analysis should be written in natural language with drawings or other graphical tools as appropriate, and the requirements should be written jointly by vendor and client. It is recommended by the GAMP guidelines that requirements decomposition should produce a description of no more than 250 words. Maintenance issues should be addressed by specifying OEE-enhancing features such as time-based alarming.
In cases where it is proposed to use a HMI or SCADA in conjunction with the PLC, consideration should be given to displaying the OEE figure. Sign-off should occur by agreement at the end of requirements decomposition, but latitude should be allowed because of the reality of the development process being iterative. Test cases should be generated from the decomposed requirements. The requirements, the decomposed requirements and the test cases should also be documented.
At the design stage it is recommended that a structure chart be the transition tool between the decomposed requirements and the PLC code modules. The PLC programming language must be IEC- 61131 compliant and should be by agreement between vendor and client having due regard to the expertise and experience of both. Module detail should be modelled by flowcharts or any other method agreeable to vendor and client.
At the implementation stage, program modules should be identified and related to the structure chart. The program modules should be documented. Code should be liberally documented by natural-language comments. I/O and all software functions should be labelled. I/O labelling should refer to any existing plant register and relevant electrical drawings.
The testing method will depend on the size of the project but will be based on the test cases developed at requirements decomposition. Testing will include both 'black box' and 'white box' testing. All test results will be documented.
The project documentation should include:
- Decomposed requirements;
- Structure chart;
- Flowchart or similar document;
- I/O list;
- Printout of programming code with natural language comments and labels;
- PLC code on CD;
- Test results.
This documentation will ensure that a quality development system is in place and the documentation can also be used as a tool for software and hardware maintenance in the future.
Procurement of bespoke services
Manufacturing companies seeking to procure a new PLC program for a new system or for a major modification to an existing system tend to rely almost totally on the vendor for guidance. In summary, many companies exhibit:
- Lack of software procurement skills
- An unrealistic (in many cases) readiness to accept the guidance of the vendor
- Poor interdepartmental communications skills
- Little concept of PLC software as an asset
- Lack of commitment in liaising with the vendor to producing detailed requirements
- A focus on the initial cost with no regard for later software maintenance cost.
A protocol for clients for the purpose of procuring bespoke PLC programs will increase the likelihood of a successful purchase. Clients, however, must be prepared to commit a person whose responsibility it is to procure PLC programs.
The nominated person, who should have expertise in software engineering and project management, will liaise internally with relevant departments such as production, maintenance and engineering to ensure that there is full and complete commitment to the new system and that there is full sharing of knowledge and expertise.
The department for which the software is required, typically the production department, must be prepared to make a subject matter expert available to develop the requirements statement, either alone or with the vendor.
The procurement person will consult with the engineering and maintenance departments to determine basic guidelines, such as the preferred PLC and programming language for the project. However, there may also be other criteria regarding hardware and electrical specifications.
The vendor may be required to allow the client's PLC and process subject matter expert to audit the project development process. The client shall require the vendor to supply documentation to validate the fact that the programming language used is IEC 6-1131 compliant and that a SDLC approach was followed in the development of the project.
The documentation required by the client are as listed above and should be circulated to the engineering and maintenance departments for comment before project sign-off. The engineering department's responsibility regarding software is to ensure that the programming language is as specified and that it is accessible, which means not pass word protected foe example.
The maintenance department must ensure that documentation is good enough to allow efficient hardware and software maintenance and both departments should also comment regarding any specific training necessary for the implementation of the new system.
Manufacturing companies often purchase special purpose machines which happen to be controlled by embedded PLCs. The company's focus is generally on the overall suitability of the machine for the purpose it was intended and the software element is generally not considered in any formal manner. A checklist is recommended for such situations.
The recommended checklist should include the following questions:
- PLC make and model;
- Programming language used;
- Whether the programming language is IEC 6-1131 compliant;
- Whether the source code accessible, i.e. is password protection in place;
- Whether the client has the necessary software and communication cable to access the source code;
- Whether the client has in-house experience with that PLC and programming language;
- Whether sufficient documentation is available with the machine to verify that a recognised SDLC development model has been followed in the development of the control software;
- Whether the documentation is sufficiently detailed to facilitate efficient software and hardware maintenance.
The consequences of negative answers to any of the above questions is variable. If the answer to the third question is negative it would result in procuring a machine with an 'exotic' control system that is incapable of being maintained and supported in-house.
Accessibility issues addressed in questions four and five can be addressed by requesting that the password be removed (question four) and by the purchase of the requisite software and communication cable (question five).
The experience issues as posed in question six can be addressed by in-house personnel with PLC experience attending a system house course for that particular PLC platform. Therefore the consequences of questions five and six being answered in the negative are not fatal but will add to the cost of procuring the machine.
The documentation questions being negative may be addressed in two ways: defer the purchase of the machine pending the delivery of comprehensive support documentation; or, purchase at a lower price and develop the documentation in-house.
The latter will pose challenges in terms of expertise and time and would probably not be feasible.
The necessity to make software-centric automated processes more efficient is obvious. Applying best software development practice will ensure a quality product that can be maintained and developed into the future.