Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC TR 62247: Industrial Automation — Programmable Controllers — Guidelines for Selection
A practical framework for selecting programmable logic controllers in industrial automation systems
IEC TR 62247, published in 2003 as a Technical Report, provides comprehensive guidelines for the selection of programmable controllers (PLCs) used in industrial automation systems. While IEC 61131 is the foundational standard that defines PLC programming languages, hardware requirements, and testing methodologies, IEC TR 62247 addresses the practical engineering challenge of choosing the right controller for a specific application. As industrial automation systems have evolved from simple relay replacement to complex distributed control networks incorporating safety functions, motion control, vision systems, and Industrial Internet of Things (IIoT) connectivity, the selection process has become increasingly multifaceted and consequential for project success.
IEC TR 62247 is not a normative standard but a Technical Report — it provides guidance and recommendations rather than mandatory requirements. Its value lies in the systematic selection methodology it presents, which covers the complete lifecycle from initial requirement definition through installation, commissioning, and long-term maintenance planning. The methodology is applicable to all controller sizes, from nano-PLCs with a few I/O points to large-scale distributed control systems with thousands of points.
Selection Criteria and Evaluation Framework
The standard organizes the selection process into a structured methodology with five principal evaluation dimensions. The first dimension is the application requirements analysis, which encompasses process I/O requirements (digital, analog, specialist modules for temperature, motion, weighing), scan cycle time constraints (typically 1-100 ms depending on process dynamics), memory capacity for program and data storage, and environmental operating conditions including ambient temperature range (0-55 deg C typical, extended ranges for harsh environments), humidity (5-95% non-condensing), vibration, and electromagnetic interference levels per IEC 61000-6-2. The second dimension addresses programmability and software ecosystem, including the required IEC 61131-3 programming languages (Ladder Diagram, Structured Text, Function Block Diagram, Instruction List, Sequential Function Chart), the availability of reusable library functions, simulation and offline testing capabilities, and version control integration.
The third dimension evaluates communication and networking capabilities, which have become increasingly critical in modern automation architectures. Key considerations include supported industrial Ethernet protocols (PROFINET, EtherNet/IP, EtherCAT, Modbus TCP), fieldbus compatibility (PROFIBUS, DeviceNet, CANopen), serial interfaces for legacy device integration, wireless connectivity for remote monitoring, and OPC UA (IEC 62541) support for horizontal and vertical data integration with enterprise systems. The fourth dimension examines reliability, availability, and safety characteristics: mean time between failures (MTBF, typically 50,000-500,000 hours), mean time to repair (MTTR), redundant CPU configurations (hot standby, cold standby), power supply redundancy, and safety integrity level (SIL) certification per IEC 61508 if the controller is used in safety-related applications. The fifth dimension evaluates total cost of ownership, which includes not just the initial hardware cost but also software licensing, engineering and programming effort, training requirements, spare parts availability, and projected maintenance costs over the system lifetime.
| Evaluation Dimension | Key Criteria | Typical Metrics |
|---|---|---|
| Application requirements | I/O count and types, scan time, memory, environment | Digital I/O count, analog resolution (12-16 bit), scan cycle time |
| Software ecosystem | IEC 61131-3 languages, libraries, simulation, diagnostics | Number of supported languages, library size, debug features |
| Communication | Industrial Ethernet, fieldbus, OPC UA, wireless, IoT | Protocol support, bandwidth, node count, real-time capability |
| Reliability and safety | MTBF, redundancy, SIL rating, diagnostic coverage | MTBF hours, redundancy type, SIL 2/3 certification status |
| Total cost of ownership | Hardware, software, engineering, training, maintenance | Cost per I/O point, engineering hours per program, spares availability |
One of the most common selection errors is underestimating the future expansion requirements. A controller selected with minimal I/O capacity for today’s needs may require complete replacement when the system is expanded. IEC TR 62247 recommends selecting a controller family with at least 25-30% spare I/O capacity, 40-50% spare memory, and the ability to add communication modules for future integration requirements. This up-front investment typically adds only 5-10% to the initial controller cost but can save 30-50% of expansion project costs later.
Application-Specific Considerations and Engineering Insights
The selection guidelines recognize that different application domains impose different priorities on the selection process. For discrete manufacturing applications (automotive assembly lines, packaging machinery, material handling), the critical factors are high-speed digital I/O response (typically 10-100 μs per input), precise timing for coordinated motion control, and the ability to handle large, distributed I/O networks. For process control applications (chemical plants, oil refineries, pharmaceutical production), the emphasis shifts to analog I/O resolution (16-bit or higher), PID loop processing capability with auto-tuning, redundant controller configurations for continuous uptime, and intrinsic safety barrier integration for hazardous area deployments. For building automation and infrastructure applications, the priorities include energy management functions, integration with building management system protocols (BACnet, KNX, LonWorks), and long-term stability with minimal maintenance intervention.
Communication protocol selection deserves special attention in the selection process. The trend toward Industry 4.0 and IIoT has made vertical integration between the control level and enterprise systems increasingly important. Controllers should support OPC UA for standardized data exchange with manufacturing execution systems (MES) and enterprise resource planning (ERP) systems. For time-sensitive networking (TSN) applications, IEC/IEEE 60802 compliant controllers enable deterministic communication over standard Ethernet infrastructure. The communication architecture should also support remote access for diagnostic and monitoring purposes, though this must be balanced with cybersecurity requirements per IEC 62443 to prevent unauthorized access to control networks.
| Application Domain | Priority 1 | Priority 2 | Priority 3 |
|---|---|---|---|
| Discrete manufacturing | Fast digital I/O response | Motion control capability | Distributed I/O support |
| Process control | Analog resolution and accuracy | PID loop capacity and tuning | Redundancy and reliability |
| Building automation | Energy management | BMS protocol integration | Long-term stability |
| Safety-critical systems | SIL 3 certification | Diagnostic coverage (DC > 99%) | Fail-safe communication |
| Distributed/remote | Wide-area networking | Wireless communication | Remote diagnostics |
IEC TR 62247 recommends a vendor-neutral selection approach, where the application requirements are fully documented before vendor evaluations begin. This prevents features of a particular brand from skewing the requirements definition. A best practice is to develop a weighted scoring matrix with the evaluation criteria specific to the application, then evaluate at least three controller families from different vendors against this matrix. The weighting factors should be determined by cross-functional team consensus, including input from electrical, process, software, and maintenance engineering disciplines.
Lifecycle Management and Long-Term Considerations
The guidelines emphasize that controller selection decisions have long-lasting implications for system maintainability and upgradeability. Key lifecycle considerations include the vendor’s product lifecycle policy — how long the controller family will remain in production (typically 10-15 years), the availability and cost of spare parts, backward compatibility with future controller generations, and the availability of migration paths when the controller is eventually discontinued. The standard recommends selecting controllers from vendors with established product lifecycle management programs and documented end-of-life notification procedures, typically providing 3-5 years advance notice before product discontinuation and 5-10 years of spare parts availability after discontinuation.
Programming environment considerations extend beyond the initial application development. The selected controller should support a programming environment that enables efficient maintenance and modification by engineers who may not have been involved in the original design. This includes structured programming practices enforced by the development environment, comprehensive online documentation capabilities, meaningful tag and variable naming conventions, and version control integration for program change management. Controllers that support object-oriented programming extensions to IEC 61131-3 provide additional benefits for managing complex automation software through encapsulation, inheritance, and polymorphism. The selection team should also evaluate the availability of local technical support, training programs, and engineering consultant expertise for the chosen controller platform.
In industrial automation engineering practice, the correct PLC selection directly impacts production line reliability, efficiency, and scalability. A well-considered selection process balances technical requirements, cost constraints, and long-term strategic planning. Controller standardization — unifying on a small number of controller platforms across an organization — can significantly reduce overall costs in engineering, training, spare parts inventory, and maintenance, while increasing engineering team proficiency and project execution efficiency. IEC TR 62247 provides a systematic evaluation framework for such standardization decisions, helping engineers make informed choices among the many available controller options.
Q1: How does IEC TR 62247 relate to IEC 61131?
A: IEC 61131 is the foundational standard for programmable controllers, covering hardware, programming languages, and testing. IEC TR 62247 provides complementary guidance on the selection process itself — how to evaluate different controllers and choose the most appropriate one for a given application. The selection criteria in IEC TR 62247 reference IEC 61131 requirements as baseline technical specifications.
A: IEC 61131 is the foundational standard for programmable controllers, covering hardware, programming languages, and testing. IEC TR 62247 provides complementary guidance on the selection process itself — how to evaluate different controllers and choose the most appropriate one for a given application. The selection criteria in IEC TR 62247 reference IEC 61131 requirements as baseline technical specifications.
Q2: What is the recommended approach for evaluating controller reliability?
A: The standard recommends using MTBF data provided by the manufacturer, validated against field experience where possible. For critical applications, a Failure Mode and Effects Analysis (FMEA) per IEC 60812 should be conducted for the complete control system, not just the controller. Redundancy configurations (hardware or software) should be evaluated based on the required availability, considering both the MTBF and the mean time to repair.
A: The standard recommends using MTBF data provided by the manufacturer, validated against field experience where possible. For critical applications, a Failure Mode and Effects Analysis (FMEA) per IEC 60812 should be conducted for the complete control system, not just the controller. Redundancy configurations (hardware or software) should be evaluated based on the required availability, considering both the MTBF and the mean time to repair.
Q3: Should the selection process prioritize open standards or vendor-specific solutions?
A: IEC TR 62247 recommends prioritizing open standards (IEC 61131-3 programming, OPC UA communication, IEC 61508 safety) to avoid vendor lock-in. However, the practical advantages of vendor-specific ecosystems — such as tighter integration, single-source support, and optimized performance — should also be considered. The optimal balance depends on the project size, expected lifespan, and organizational capabilities.
A: IEC TR 62247 recommends prioritizing open standards (IEC 61131-3 programming, OPC UA communication, IEC 61508 safety) to avoid vendor lock-in. However, the practical advantages of vendor-specific ecosystems — such as tighter integration, single-source support, and optimized performance — should also be considered. The optimal balance depends on the project size, expected lifespan, and organizational capabilities.
Q4: How often should the controller selection be revisited for an existing installation?
A: The standard recommends a technology review every 3-5 years for existing installations. Trigger events for immediate reassessment include: end-of-life announcements from the current controller vendor, major process changes requiring significant I/O capacity expansion, cybersecurity vulnerability discoveries requiring hardware-level mitigation, or the emergence of new communication standards that provide significant operational benefits.
A: The standard recommends a technology review every 3-5 years for existing installations. Trigger events for immediate reassessment include: end-of-life announcements from the current controller vendor, major process changes requiring significant I/O capacity expansion, cybersecurity vulnerability discoveries requiring hardware-level mitigation, or the emergence of new communication standards that provide significant operational benefits.
