An Operator Turing Test
Dale Peterson
ICS Security Catalyst, Founder of S4 Events, Consultant, Speaker, Podcaster, Get my newsletter friday.dale-peterson.com/signup
Proposal: A small group in the ICS world develop a test to determine if a "machine" can be trained from only historian data to perform as good (indistinguishable) or better than a representative Operator.
In 1950 Alan Turing wrote an article on what he called "the imitation game" in an effort to answer the question "can machines think". It was based on whether a human monitoring text communication between two parties could identify if either was a machine. Or in other words, was the machine indistinguishable from the human.
The buzzwords are flying in ICS these days with artificial intelligence (AI), machine learning (ML), and ICS in the cloud. Some instantiations are widely accepted such as using digital twins and machine learning for predictive maintenance and efficiency studies. Others, such as using machine learning for process variable anomaly detection, have been proven in examples if not yet deemed practical in general. However, when one suggests that Operators will be replaced with machines this decade, this is usually considered heresy.
When you look at the data available and the function, replacing Operators with machines is actually the easiest of the three tasks described in the above paragraph. Consider:
- Operators are trained to perform a consistent set of actions based on information provided to them. When you see this, do that. Operator training, whether in materials, simulators or side-by-side a skilled Operator, consists of this standard output/action based on a set of input seen on the HMI.
- A capable Historian has collected years, sometimes decades, of this input/status of the physical process, the subsequent Operator action, and the resulting change in the status of the physical process. This is the data needed to train the machine.
- When Operators run into a situation that does not make sense based on their experience or indicates there is likely a failure somewhere in the ICS or process, the Operators have a set of call outs to engineers or other staff. An Operator is not an engineer, and is not expected or asked to go beyond their skill set.
The last bullet is sometimes not true. There are some extraordinary Operators who know and can troubleshoot the ICS process as well as the engineers that designed it. This is why I used the adjective "representative" before Operator in the proposal. If the machine handles the drudgery of normal operations, this would free the extraordinary Operators to do the more valuable work of being Trainers, Maintainers and Sustainers to the AI/ML as described in the book Human + Machine.
The Operator Turing Test
There are a number of ways this test could be created. An asset owner or vendor could create and run the test on their own. Ideally it would be a pairing of an asset owner, to provide years of historical data and representative Operators, and a vendor, to help with the simulation and replay.
Once the test is constructed and tested with the Operators, then the historical data could be provided to any teams that wanted to take on the test. The actual test of the Operator and machine would not need to be run simultaneously as all we need are the results, the actions captured in the Historian.
Speed of action should not be a factor in comparing the Operator and machine. It is almost certain the machine will be faster. The judging or evaluation could look at:
- Did the machine take the same action as the Operator?
- Where they differed, was the machine action or Operator action superior?
- The number and necessity of the machine and Operator callouts for special situations.
The team developing the test would need to identify the factors that would measure performance in advance to determine "superior" and a scoring mechanism. Case by case analysis of variations is possible and may be worthwhile. How practical it is would be determined by the number of instances where the actions were different.
I'd be very interested in assisting anyone who wants to create this Operator Turing Test, and would love to be able to either provide details on the test or the results (can we move that fast?) at S4x22 next January.
Subscribe to my ICS Security: Friday News & Notes email.
Senior Vice President
4 年Dale, you have opened a can of worms on this one. The ideas and efforts to minimize the "human element" in operations has been around for a long time, and to various degrees has been implemented. There is no doubt that industry has made progress in this area - the vast majority of industrial processes require far fewer operators than they did several years ago. Why? Improvements in automation. Will AI and ML play a bigger role in this journey to increased automation? It certainly will, and to what extend and how fast, we shall see. But there is another important technological hurdle to be addressed. AI and ML today are good at modeling and operating on "known" data (seen it before, know what to do when it happens again). AI and ML are not very good at "extrapolating" beyond what it has seen before. It's getting better, but a long way to go. The reality today is that operators provide the most value when things go bad, not during routine operations. It's 3 o'clock in the morning, things start to go bad, the process is getting crazy, and you have to act to avoid a shutdown that will happen in a few minutes (or even worse), the experienced operator who can draw upon their knowledge, make sense of what is going on, figure out what to do, and correct the issue, is worth their weight in gold. AI and MI are a long way from replacing that in the near term. Fun topic, thanks for bringing it up.
Backend engineer & leader | ICS/OT protocol DPI & security
4 年Really interesting article. One thing that came to mind is the use of something from the CI/ML world called adaptive critic designs. Essentially, an adaptive design uses 2 neural networks to learn a control a process and then improve it over time. The first neural network (called the "actor") models its initial behavior after a conventional/known process (in this case process status and operator action from the HMI), while the second (called the "critic") modifies the actor network to improve its actions over time. Of course, "how" it improves those decisions depends on some cleverly crafted utility function and optimizes for one or more outcomes. I had used an adaptive critic design in grad school simulations to optimize the dispatch of electricity in a microgrid, trying to optimize utilization of photovoltaics and wind generation with battery storage. I wonder how feasible training an actor network from the HMI data would be, and then what a utility function to optimize that would look like...
Manager for OT/ICS/xIoT Cybersecurity Development. Senior Advisor for Regulation, Risks and Emerging Technologies Landscape
4 年Last for conclusion. AI for process can be useful but needs training from process engineers and good historical data. After that, the AI will need second training phase with model validated on real scenario. Only possible for technologies that can give you opportunity for this second chance with margin for failure. Most critical ones will not, but I am sure that many applications will
SVP Growth & Strategy @ Frenos | OT Security | GICSP | Texas MBA | Former Nozomi | Former GE | Public Speaker
4 年I've no doubt that in increasingly varied scenarios, AI/ML will yield more efficient and safer outcomes in process operation. However that only means the role of the operator evolves to a higher level of sense-making. As Colin Parris puts it during his Digital Ghost talk, revert to a deterministic or manual action when the AI is outside of its region of competency.
Manager for OT/ICS/xIoT Cybersecurity Development. Senior Advisor for Regulation, Risks and Emerging Technologies Landscape
4 年2) I remember the most complex project I've ever run, to modernize a analogic level control for a nuclear reactor with a modern TMR digital solution. Once the theoretical models and FAT tests had been approved we had to take the model to the full-scope simulator (I only know of such level of detail in nuclear, perhaps avionics but without reactivity to calculate) , adjust critical parameters by using historical transient data. It was heavy but finally worked. Those final parameters were the starting-point for the real plant startup and it took a ultra-detail procedure to test every point where any parameter would be subject to be tested. No single initial date remained the same, was the previous training useful? absolutely! that previous work allowed a complex startup without trips. The training could be considered enough? absolutely not, the methodology was run again in the real plant and the response was different, so the "tunning training" was needed again, and no margin for failure. And another thing, when we run accident simulations, there is one part for engineers and another for operators, both needed and both helping the other to revise and improve their counterpart.