|
Agile Automation refers to the application of select Agile software development principles, patterns and practices, to the area of industrial automation and process control software development. The term was coined by HAL Software (Ireland) in 2013. The original idea was to simply borrow some of the principles from modern software development. For example, providing a mockup/prototype or 'conference room pilot' at the start of a sprint to convey to stakeholders, what was going to be delivered by the end of the sprint. However some approaches such as unit testing cannot easily be borrowed, because the proprietary nature of industrial programming languages do not allow for unit testing and class modification through extension only. If unit testing is implemented, it is invariably through an open source language and libraries such as Python and an interface API technology such as OPCDA or OPCUA. Both HAL Software, and CoDeSys took this approach) Traditionally, industrial automation software has been developed using languages that do not fully implement object-oriented programming. Software development lifecycle is in line with the Waterfall model. For example, the GxP (Good Automated manufacturing practice) V model that is pervasive throughout the pharmaceutical regulated industries. There was a growing belief however that the model was too rigid, did not allow for sufficient change throughout the software development lifecycle and did not target testing according to risk. The latest version of the GxP model went some way towards testing based on risk assessment. The latest GxP model advocates testing and documenting according to perceived risk to the end user. (The patient, in the case of the Pharmaceutical industry). In fact the GAMP5 guide in 2008 explicitly mentioned Agile programming; :"The approach described in this document is designed to be compatible with a wide range of other models, methods, and schemes, including: Software development methods such as RAD, Agile, RUP, or Extreme programming." (GAMP5) There is debate however over whether Agile methods can truly satisfy regulatory requirements, as outlined in the article on Alternative Software development models and methods in GxP Environments, by ISAP GMAP D_A_C_H SIG ASDMM. (Pharmaceutical Engineering Jan2012 Vol32 No.1). The Industry has some experience of poorly executed manufacturing execution system Agile software projects and these experiences have tended to reinforce the traditional notion that Waterfall software development lifecycle is the simplest way to enforce Engineering Rigour and budgetary/schedule constraints on a software development team. As of 2025, Agile project management has made in-roads into the regulated industries, especially regarding IT system rollouts. It is often down to the project managers preference as it is debatable which approach is better. In the hybrid area of IT/OT (Where information technology or traditional IT applications are integrated with Operations technology or custom industrial control applications), the use of various variants of the Agile methodology is common. However it is still hampered by the fact that GxP change control in a regulated industry follows a planned sequence/order of events which is 'waterfall' in nature. Agile Automation software development has the potential to reduce the development lifecycle and at the same time, encompass automated unit testing. Something that the industry is calling for. In addition, the "don't repeat yourself" aspects of Agile object oriented software development encompassing extension of software classes through interfaces (Software class is open for extension but closed for modification) are very attractive in a regulated industry where software change validation is particularly expensive. Agile software development promotes true object oriented software programming which in turn results in software that is more amenable to change and less likely to break. The two most widely used strategy design patterns in Pharmaceutical and other Batch Industrial Automation higher level systems (SCADA, Batch and MES ) are ISA S88 & ISA S95. These patterns can be implemented such that the action behaviours (e.g., read/write method or Valve command on/off method) are encapsulated as interfaces using languages such , or Java. Commercial Control System software development is biased towards inheritance and subtyping, and the other OOP tenets (Encapsulation, Polymorphism) are not exposed to the programmer to the same extent. This incomplete OOP implementation increases the amount of design effort required. Even Commercial Proprietary DCS systems such as Emerson DeltaV are biased towards subtyping and inheritance without an easy way to implement a behaviour through an interface or similar construct. (There is no way to implement multiple inheritance.) The IEC 61131-3 programming language is the most widely used language for programming PLC & DCS systems. It is not a truly object oriented language, implementing only 1 tenet of OOP (inheritance/subtyping) and not encapsulation or polymorphism. This limits its amenability to automated unit testing and encapsulating of behaviours for class extension. Generally there is less scope for encapsulating behaviours in most industrial controllers except for platforms that run a more advanced operating system (for example the Beckhoff Twincat platform) that can be programmed via high level IDEs such as visual studio. There is a replacement standard (IEC 61499) that is more object oriented, but industry uptake had been small up until recently (2024) .There is however now a new industry/university initiative centred around the organisation behind https://universalautomation.org. In addition, an 'open process automation forum ' (OPAF) initiative driven by Exxon mobile since 2014 (but now managed by https://www.opengroup.org/) essentially looks to standardise both hardware and software components in a process automation system with the benefit of reduction in 'vendor lock in'. As of 2025, companies such as Schneider electric have even open sourced / released an iec61499 runtime so that other vendors can create engineering tools and develop, simulate and test code all within the same PC application. There are moves towards IEC61131-3 consolidation, notably through the PLCOpen standard. This approach to developing an abstract XML class can result in a library of tested class modules/types that can subsequently be instantiated and imported to target platform. There was some interest in model driven architecture (MDA) Agile programming whereby a platform independent model is first developed. As a result of regulatory filing requirements and the need to protect against litigation, the Pharmaceutical industry records and saves data that must be reconstituted for subsequent filing submittal or Batch release (Electronic batch records). A model developed in the pilot lab and used as the guideline for manufacturing scale up, can aid filing submittal. However by 2025, a majority of new initiatives are re-orienting towards machine learning for the purpose of developing re-useable models.Organisations such as opc foundation now have dedicated AI working groups.
|
|
|