In speaking with some industry experts the feeling was it is the 'same old same old', but digging beneath the surface there are many significant changes taking place – in fact far too many to cover in a single article, so look out for more in future issues of SA Instrumentation and Control.
The Internet has been driving the use of XML (eXtensible Mark-up Language) technology. XML is easy to use, easy to read at both the human and machine level and XML data can be formatted independently from its data content through the use of style sheets and XML reporting utilities.
XML was introduced into the PLC/PAC/DAC communication and programming world through such initiatives as OPC XML-DA, BatchML, B2MML and PLCopen XML – each of which cover some subset of engineering in an automation and control project.
Version 1.00 of the OPC XML-DA specification was released in July 2003 and the OPC UA (Unified Architecture) specification incorporates XML data formats.
Version 1.01 of the PLCopen XML schema and documentation was published in June 2005 and in May 2009 the PLCopen XML schema version 2.01 was released. This latter covers, inter alia, the following use cases:
* Exchange format for programming tools (all IEC languages).
* Interface to producers of graphical and logical information.
* Interface to consumer of graphical and logical information.
* Distribution format for function block libraries.
While there are many individual organisations and vendors providing diverse XML based applications – they are just that. The current engineering landscape of 'islands of (XML) data' parallels the old 'islands of automation'. Users and SIs have pieces of engineering data in XML format but no easy way of bringing these all together.
In April 2009 an industry group comprising ABB, Daimler, Fraunhofer IITB, NetAllied Systems, Otto-von-Guericke-Universität Magdeburg, Siemens and Zühlke established AutomationML e.V. – a development company to accelerate the use of open interfaces for digital factory and shop floor automation systems. Anton Hirzle of Daimler was elected as chairman of the Board; he will be supported by deputies Dr Wolfgang Schlögl (Siemens) and Volker Miegel (ABB).
AutomationML promotes itself as 'The glue for seamless automation engineering'. Quoting from AutomationML Specification Part 1 – Architecture and General Requirements Version 1.1, “AutomationML (Automation Mark-up Language) is an XML schema-based data format designed for the vendor independent exchange of plant engineering information. The goal of AutomationML is to interconnect engineering tools from the existing heterogeneous tool landscape in their different disciplines, eg, mechanical plant engineering, electrical design, process engineering, process control engineering, HMI development, PLC programming and robot programming.
“AutomationML stores engineering information following the object oriented paradigm and allows modelling of real plant components as data objects encapsulating different aspects. An object can consist of other sub-objects, and can itself be part of a larger composition or aggregation. It can describe eg, a signal, a PLC, a tank, a control valve, a robot, a manufacturing cell in different levels of detail or a complete site, line or plant. Typical objects in plant automation comprise information on topology, geometry, kinematics and logic, whereas logic comprises sequencing, behaviour and control.
“AutomationML combines existing industry data formats that are designed for the storage and exchange of different aspects of engineering information. These standards are used on ‘as-is’ basis within their own specifications and are not branched for AutomationML needs.
“The core of AutomationML is the top-level data format CAEX that connects the different data formats. Therefore, AutomationML has an inherent distributed document architecture.”
AutomationML proponents point to the fact that engineering and commissioning make up as much as 50% of factory automation costs and to the problem of the heterogeneous nature of software tools used in plant engineering. This latter results in a plethora of paper interfaces, which contribute to complexity, inaccuracy and inefficiency.
An important aspect of AutomationML is that it does not intend to supersede other XML-based standards such as PLCopen XML, but rather to embrace such standards – thus one of the normative references in AutomationML v1.1 is PLCopen XML: Technical paper PLCopen technical committee 6, XML formats for the IEC61131-3, version 2.0.
Most vendors have now adopted common tag databases, meaning that there is no longer a need to document cross-reference tables between PLC/PAC tags and their equivalents in associated scada or HMI systems.
Opto 22’s PAC Project Software Suite provides an integrated development environment (IDE) for programming and a suite of related programs for HMI (human machine interface) development and other purposes. Through common tagging, names and definitions set up in one of the suite’s applications are available for use in the others. This means that a variable bears the same identity in the PAC, HMI and OPC interfaces for example.
Omron’s CJP PAC, NS-Series HMI’s and middleware all share the same tag database. Each Omron CJ2 CPU has a tag name server to manage tag names and I/O addresses. This enables access from external devices using tag names, without needing to know the I/O addresses.
Rockwell’s common tag-based programming structure, allows tag names to be defined once but shared between controller programs, HMI and other applications.
Application software represents a significant investment for an organisation. As mentioned above, up to 50% of an automation project’s costs occur as part of engineering and commissioning. But what tools are available for managing these soft assets?
According to Dave Woll, ARC VP, Consulting Services, “… an overwhelming majority of users struggle to maintain accurate and current records of the configuration and programming of their automation assets. At the same time, users indicated a clear understanding of the consequences of not having accurate records.”
Rockwell Automation has been busy expanding the capabilities of its FactoryTalk AssetCentre. This product secures access to control system configuration (application software and device configurations), tracks user changes and provides secure backup and restore services. The latest release of AssetCentre adds support for process device configuration using field device tool (FDT) technology and disaster recovery support for Rockwell Automation and third-party controller, operator interface and robotic assets. These disaster recovery capabilities provide control system backup that is integrated with source control helping end users to ensure that restores are performed from the most up-to-date control system configuration files.
MDT Software specialises in CMS (Change Management Systems) for programmable automation systems like PLCs, PACs and DACs. The software developer is named in ARC Advisory Group’s recently released solution guide: “Configuration Management for Automation Assets”.
MDTs flagship software product, AutoSave, is designed to protect, save, restore, discover, and track changes in PLCs, HMIs, SCADA systems, robots and other industrial programmable devices and documents.
The software features:
* An archive of prior revisions of programs.
* The ability to detect and provide notification of changes.
* Secured user and workstation access.
* A historical record of who made the program change, when and from where it was made.
* The ability to compare programs on-demand and on an automatic schedule.
In South Africa, MDT is represented by Wonderware.
CAEX (computer aided engineering exchange) is a neutral data format that allows storage of hierarchical object information, eg, the hierarchical architecture of a plant. On a certain abstraction level, a plant consists in modules or components that are interconnected. CAEX allows storage of those modules or components by means of objects. Object oriented concepts as encapsulation, classes, class libraries, instances, instance hierarchies, inheritance, relations, attributes and interfaces are explicitly supported. CAEX is based on XML and is defined as an XML schema (xsd file). The original intention of developing CAEX was to address the lack of a common and established data exchange between process engineering tools and process control engineering tools. However, CAEX can be applied to all types of static object information, eg, plant topologies, document topologies, product topologies, Petri Nets, but also for non-technical applications like phylogenetic trees. (www.wikipedia.com)
CAEX is embodied in IEC 62424:2008(E) – Representation of process control engineering – Requests in P&I diagrams and data exchange between P&ID tools and PCE-CAE tools.
This IEC standard specifies how process control engineering requests are represented in a P&ID for the automatic transfer of data between P&ID and PCE tools and to how to avoid misinterpretation of graphical P&ID symbols for PCE. It also defines the exchange of process control engineering request relevant data between a process control engineering tool and a P&ID tool by means of the CAEX data transfer language.
About the author
Andrew Ashton has electrical, mechanical and business qualifications and has been active in automation and process control since the early 1980s. Since 1991 he has headed up a company that has developed formulation management systems for the food, pharmaceutical and chemical manufacturing industries and manufacturing solutions involving the integration of various communication technologies and databases. Developed systems address issues around traceability, systems integration, manufacturing efficiency and effectiveness. Andrew is features editor for SA Instrumentation and Control and editor of Motion Control in Southern Africa.
|Tel:||+27 11 543 5800|
|Fax:||+27 11 787 8052|
|Articles:||More information and articles about Technews Publishing (SA Instrumentation & Control)|
© Technews Publishing (Pty) Ltd | All Rights Reserved