From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Triconex is both the name of a Schneider Electric brand that supplies products, systems and services for safety, critical control and turbomachinery applications and the name of its hardware devices that utilize its TriStation application software. Triconex products are based on patented Triple modular redundancy (TMR) industrial safety-shutdown technology. Today, Triconex TMR products operate globally in more than 11,500 installations, making Triconex the largest TMR supplier in the world.

Company History: The history of Triconex was published in a book called 'The History of a Safer World' by Gary L. Wilkinson. The company was founded in September, 1983 by Jon Wimer in Santa Ana, California and began operations in March, 1984. The business plan was written by Wimer and Peter Pitsker, an automation industry veteran and Stanford graduate. They presented the plan for a TMR (Triple Modular Redundant) based system that would improve the safety and reliability in industrial applications. Among the customers they targeted were the petro-chemical giants, such as Exxon, Shell, Chevron, and BP.

Pitsker and Wimer presented the business plan to Los Angeles based investor Chuck Cole, who was also a professor at USC. Cole was interested, so he contacted his personal attorney, future two-time Los Angeles Mayor Richard Riordan. Riordan agreed to invest $50,000 and Cole's venture capital team matched it, providing the seed money for Triconex. After two years, however, the company nearly failed due to the expense and complications of testing a new safety system. In February, 1986, founder Wimer left the company and the board asked a seasoned executive, William K. Barkovitz to become CEO. Barkovitz ended up leading the company for 9 years. At the end of his term, Triconex became the leading safety system in a market it largely created, made acquisitions, and completed an IPO. In January, 1994, Triconex was acquired by British based SIEBE for 90 million dollars.

The hardware architect of the Tricon was Gary Hufton, the Software development manager was Glen Alleman. These managers, with Wing Toy (the lead engineering of the fault tolerant ESS telephone switch), led a small successful engineering team that built the first Tricon, sold in June, 1986. Soon after, Exxon became a customer and automation giant Honeywell agreed to distribute the Tricon. Among the software engineers who worked for Triconex were Phil Huber and Dennis Morin, who later left the company to found Wonderware, also based in Irvine California which became the world's leading supplier of Human Machine Interface (HMI).


The triconex system is based on the TMR patented technology that supports up to Safety Integrity Level 3SIL 3 and is usually used as a safety rather than control system.[1]

Operating theory[edit]

Fault tolerance in the Tricon is achieved by means of a Triple-Modular Redundant(TMR) architecture. The Tricon provides error-free, uninterrupted control in the presence of either hard failures of components, or transient faults from internal or external sources. The Tricon is designed with a fully triplicated architecture throughout, from the input modules through the Main Processors to the output modules. Every I/O module houses the circuitry for three independent legs. Each leg on the input modules reads the process data and passes that information to its respective Main Processor. The three Main Processors communicate with each other using a proprietary high-speed bus system called the TriBus. Once per scan, the three Main Processors synchronize and communicate with their two neighbors over the TriBus. The Tricon votes digital input data, compares output data, and sends copies of analog input data to each Main Processor. The Main Processors execute the userwritten application and send outputs generated by the application to the output modules. In addition to voting the input data, the TriBus votes the output data. This is done on the output modules as close to the field as possible, in order to detect and compensate for any errors that could occur between the Tricon voting and the final output driven to the field.


The Triconex system usually consists of the following typical modules:[2]

  • Main Processor modules (triple).
  • Communication module(s) .
  • Input and output modules: can be analog and/or digital and work singular or in hot-spare (standby).
  • Power supply modules (redundant).
  • Backplane(s) (chassis) that can hold the previous modules.
  • System cabinet(s): can compact one or more chassis in one cabinet.
  • Marshalling cabinets to adapt and standardize interface connections between the field instruments and the Triconex system cabinets.
  • Human machine interface (HMI) to monitor the events.
  • Engineering workstation (EWS) for programming. monitoring, troubleshooting and updating.


The Triconex main processors can communicate with the so-called TriStation 1131 application software to download, update and/or monitor programs.[3] These programs are either written in:

Besides, a Sequence of Events (SOE) recorder software and Diagnostic monitor software are implemented.

Triton malware[edit]

In December 2017 it was reported that the safety systems of an unidentified power station, believed to be in Saudi Arabia were compromised when the Triconex industrial safety technology made by Schneider Electric SE was targeted in what is believed to have been a state sponsored attack. The computer security company Symantec claimed that the malware, known as "Triton", exploited a vulnerability in computers running the Microsoft Windows operating system.[4]

References and notes[edit]

  1. ^ Safety Considerations Guide for Tricon v9 Systems, © 2004 Invensys Systems, Document No. 9720097-001
  2. ^ Technical Product Guide Tricon Systems, © 2006–2007 by Invensys Systems, Inc.
  3. ^ Developer’s Guide-TriStation 1131, Version 4.1© 2004 Invensys Systems, Document No. 9720100-001
  4. ^ Gibbs, Samuel (2017-12-15). "Triton: hackers take out safety systems in 'watershed' attack on energy plant". The Guardian. ISSN 0261-3077. Retrieved 2017-12-16.

Brody, Ken. (1985). TOLERATING FAULTS.. 58. 35-40. The success of fault tolerance in spacecraft control systems has encouraged more down-to-earth users to consider it for their process controllers, programmable controllers, and on-line processing systems. While suppliers are working to meet these expectations, no real standards are available to define fault tolerance, nor is there any general agreement on the means to achieve it. In fact, different systems tolerate faults to widely varying degrees. The purpose of this article is to shed some light on the various degrees and types of fault tolerance, provide some useful examples of fault-tolerant features, and to suggest a classification scheme for both fault tolerant computer systems and applications. This article was written while I was Vice President of Research and Development at Triconex and the number 2 founder. My team completed a working prototype under my direction before Gary Hufton was even hired. I have the design documents with their dates. Published history is an inaccurate revision of events.

Further reading[edit]

External links[edit]