From PLC, PAC, to Schneider's automated open system

      PLC has more than 40 years of development history to replace relay-based systems. Conceptually, they are similar and use ladder logic, which mimics the appearance of wiring diagrams that engineers use to represent physical relays and timers and the connections between them. The early PLC required a dedicated terminal for programming, with very limited memory and lack of remote I/O.

       In the 1980s, PC-based software was introduced into PLC programming, and as time passed, it became faster and faster, and more functions were added. Since then, many new technologies have been applied to PLCs, greatly expanding their functions on an almost continuous basis. PAC is relatively new in the automation market, using a term coined by market research company ARC in 2001. Since then, no specific agreement has been reached on the difference between PAC and PLC. Some users think that the term PAC is just a market jargon for describing advanced PLCs, while other users think that there is a certain difference between PLC and PAC. 

The market research company ARC has specified five characteristics that define PAC:

  • Multi-domain function
  • Single, multi-disciplinary development platform
  • Flexible software tools to maximize the flow between machines or processes
  • Open modular architecture
  • Compatibility with corporate networks

         

Basic characteristics of PAC       

 Since there is no industry standard definition of PAC, the distinction between PAC and PLC is very fuzzy. High-end PLCs now have some of the above characteristics and are eroding products that were once regarded as the PAC field. In fact, many PLCs now include standard programming languages, the ability to expand functionality through additional modules, and connections to various bus systems.

      No matter what, sometimes we don't need to struggle with the exact definition of PAC. The difference between PLC and PAC can be seen from the currently popular so-called PAC products

Adopt a more open architecture and modular design

      PAC provides a more open architecture and modular design to promote communication and interoperability with other devices, networks and enterprise systems. They use standard protocols and network technologies (such as Ethernet, OPC and SQL), so they can be easily used for communication, monitoring and control between various networks and devices.

       PAC also provides a single platform that operates in multiple fields (such as motion, discrete and process control). In addition, the modular design of PAC simplifies system expansion, and simplifies the addition and removal of sensors and other equipment, usually without disconnecting the wiring. Their modular design makes it easy to add and effectively monitor and control thousands of I/O points

Build a distributed control system

         Stronger network communication protocols are introduced into PAC, such as CANOpen, Ether/IP.OPC UA, TCP/IP, MQTT, etc. to build a distributed control system. The reason for this is that data can be exchanged between devices and applications in different fields, such as motion and process control.

Ability to handle large amounts of analog IO

        For simple applications (such as controlling basic machines), PLC is a better choice than PAC. Similarly, for most applications that are mainly composed of discrete I/O, PLC is the best choice, unless there are other special requirements, such as large amounts of data processing and operations. If the application includes monitoring and controlling a large number of analog I/O points, then PAC is usually a better solution. This is also the case when the application program includes the entire factory or factory floor. This situation usually requires a large number of distributed I/O and extensive loop control. This function is more suitable for PACs than PLCs.

Stronger ability to process data

Such as log records, database access, can exchange data with enterprise information systems more conveniently

Schneider's PLC/PAC products

The distinction between Schneider's PLC and PAC is not obvious. Some products (such as M251) in the document are called PLC, sometimes called PAC, and recently called dPAC (Distributed PAC). That's it anyway. I care about M251 and M580

  Modicon M251 Logic Controller

 

M251 is a small modular PAC product that can be expanded with various TM-3 IO modules.

 

M580

This is Schneider's larger modular PAC. It simply uses Ethernet as the backplane bus. The ARM microprocessor used in the M580 ePAC is a SPEAr dual-core multi-function CPU, manufactured by ST Microelectronics in cooperation with Schneider Electric. And provides more Ethernet ports. 

Programming of PAC products

        PAC programming still uses IEC61131-3 (ladder diagram, function block diagram, sequential function diagram, instruction list or structured text). However, PAC provides tag-based programming. With PAC, a single tagname database can be used for development, while a software package can program multiple models. Before binding to a specific I/O or memory address, tags or descriptive names can be assigned to functions. This makes PAC programming highly flexible and can be easily extended to large systems.

The names of Schneider PAC's programming tools are also constantly changing. Now called EcoStruxure™ Machine Expert (formerly SoMachine platform)

 

Automated Open System

On November 5, Schneider Electric released a new open automation platform-EcoStruxure open automation platform at the 3rd China International Import Expo (hereinafter referred to as CIIE). This has triggered a heated discussion about open platforms in the industry. However, Schneider is different from Apple. Once the conference is over, the documents, specifications, and prices are all out. And Schneider's website can hardly find relevant information and catalogs. From Schneider’s past series of evolutions and some news from seminars, Da Ai can see some clues:

  • The open platform will be based on the IEC61499 development environment of nxtControll which they acquired before, and the runtime will be combined with Schneider EcoStruxure, called: EcoStruxure Automation Expert (EAE).
  •  M251, M580 PAC and Altivar Drive are the hardware platforms of IEC61499.

From Schneider's April 2020 document "Modicon M251/M580 Distributed PACs and Altivar Drives with EcoStruxureTM Automation Expert Hardware Reference Guide" article, we can see that M151/M580/Altivar Drive contains IEC61499 function blocks, but there are very few FB types.

It can be basically seen that Schneider will integrate IEC61499 more into PAC and EcoStruxure. However, edge computing elements such as docker containers are used in industrial PCs. Build their open system. Furthermore, they hope to build a model similar to the mobile App store, encouraging third-party software developers to independently develop IEC61499 functional block libraries and microservices. Form a multi-party ecosystem. Of course, there is nothing more to refer to. I may also misunderstand.

Let’s talk about personal views on automated open systems

I feel that a system must be truly open. At least the following points need to be achieved:

1 Software and hardware decoupling

   The applications developed for manufacturer A can run directly on the hardware of manufacturer B.

2 System and vendor decoupling

A system can use either A manufacturer's hardware or B manufacturer's hardware. And it can be deployed, operated, maintained and updated under a unified software

3 Software environment and device decoupling

Different manufacturers use open software operating environments, such as Linux OS, Docker container technology, hardware drivers, and module buses all use open technology. And open to users. It uses PCI bus, USB interface, etc. just like a PC.

I guess it will be difficult to fully achieve these three points. Now it is probably only possible that users can write IEC61499 applications and images in some docker containers. A large number of functional blocks in the controller are related to the hardware IO module. The IO modules of different hardware manufacturers are not the same. The system is decoupled from the manufacturer, and IEC61499 products developed by a third party can be incorporated into Schneider's system. This depends on whether Schneider opens the IEC61499 command protocol. If it is also an XML format standard, it is also possible.

(This article is my own experience and consideration of reading the information, not necessarily correct, for reference only, welcome to remind and correct)

Guess you like

Origin blog.csdn.net/yaojiawan/article/details/109613641