FDT Group’s latest significant release seems to be gaining traction. This release from M&M Software offers a migration path for users and vendors supporting modern intelligent device management and monitoring initiatives.
M&M Software released fdtCONTAINER version 4.8, a point-to-point device configuration tool supporting the latest FDT 3.0 specification to meet user demands for modern intelligent device management and monitoring initiatives. This release also includes updated developer tools which simplify the migration to FDT 3 systems and smart device DTMs for the vendor community.
Smart manufacturing initiatives drive end users and suppliers of industrial automation systems and devices to seek modern and comprehensive device management solutions that use interoperable, efficient, and sustainable plug and play engineering tools. FDT, an IEC 62453 embedded software standard, normalizes device data and communication between any host and device. The standard rooted in the host and device environment provides users a single tool for intelligent device management, operation, diagnosis, and maintenance. The latest FDT 3.0 specification enables a FDT Unified Environment (FDT UE) for IT/OT data-driven operations via authenticated OPC UA, FDT UE and mobile clients.
M&M Software’s FDT UE-ready product line includes:
- OEM fdtCONTAINER application 4.8 – Free point-to-point device management and configuration tool supporting all DTM generations for users.
- fdtCONTAINER component 4.0 (aka. FDT UE – Desktop Common Component) – The official component for integrating the FDT 3.0 interface and DTM runtime into an engineering application for system vendors with branded customizations and other value-add features.
- dtmMANAGER development suite 4.0 – The comprehensive FDT 3.0 DTM development suite provides a simplified environment for device vendors to develop DTM’s allowing vendors to focus on the value-add device model features.
Still catching up on news I learned at ARC Industry Forum in early February. This one is expansion of the device integration model enabled by the latest version of FDT. Earlier, I wrote about Migrating to FDT 3. I sat in a couple of sessions where a senior engineer at a consumer packaged goods company pleaded with suppliers to make integrating and applying technologies more user-friendly. This is one such technology.
FDT Group announced that the PACTware consortium released its latest software version, PACTware 6.1, based on the latest FDT3 standard. PACTware 6.1 is one of the first FDT3 stand-alone device configuration environments available. The software tool’s source code is available to the PACTware Consortium membership consisting of 22 automation vendors who offer the FDT-enabled hosting product to the user community at no cost.
By leveraging the modern FDT3 Unified Environment for intelligent device management, PACTware 6.1 users will enjoy the ability to support their current FDT DTM install base and support modern FDT3 web-based DTMs that are scalable for IIoT architectures. This release also supports integration with FDI Device Packages.
Suppliers of industrial automation systems and devices want to provide solutions that enable the Industrial Internet of Things (IIoT). To meet their customers’ needs, it is vital for suppliers to enhance their system and device offerings with standards-based, platform-independent, information-driven business models. The new FDT3 standard is accelerating the digital manufacturing journey by enabling an ecosystem of FDT-based solutions providing a unified environment for industrial device management with IT/OT data-driven operations.
In addition to the new FDT3 standard that fully describes the FDT Desktop environment and FDT web-based device DTM, the standard also defines a cloud-based FDT Server environment for distributed control. The new FDT3 DTM and FDT Server are OPC UA- and -mobile ready without any coding, allowing users an easy to use and scalable migration path of OT data to IT enterprise applications.
Every morning last week I listened to presentations from OPC Day–which was actually a week. Once again this year was a conference reporting on a vast amount of work done by volunteers from numerous companies that push forward the cause of interoperability in manufacturing/industrial data communications. Earlier this year, I visited the ODVA annual general meeting. This virtual conference by the OPC Foundation is well worth a listen.
There were two or three presentations on MQTT where speakers tried mightily to tread the line between simplifying and explaining how these are not competing technologies and yet evangelizing the benefits of OPC UA over MQTT versus Sparkplug B. The presentations were balanced for the most part. OPC UA is a substantial information model. MQTT is a lightweight transport protocol widely adopted by IT. Sparkplug B is a lightweight information model requiring some extra defining work by the integrators but keeps overhead low. Obviously, there is a place for each.
I’ve added a list of videos from the OPC Foundation YouTube channel for your viewing pleasure:
Day 1: https://youtu.be/2i54Q-2IvCQ
Day 2: https://youtu.be/CsXagNmWWjY
Day 3: https://youtu.be/8XuTAcG598o
Day 4: https://youtu.be/ezSRRaG1fAE
Day 5: https://youtu.be/ZzS7Z8a7c1I
I applaud these efforts to improve and increase digital interoperability through industry or formal standards and open source. These efforts over many years, and even ones that pre-date digital, have provided progress not only in technology but in the lives of users. This announcement comes from the Digital Twin Consortium, a project of The Object Management Group (OMG).
Digital Twin Consortium (DTC) announced the Digital Twin System Interoperability Framework. The framework characterizes the multiple facets of system interoperability based on seven key concepts to create complex systems that interoperate at scale.
“Interoperability is critical to enable digital twins to process information from heterogeneous systems. The Digital Twin System Interoperability Framework seeks to address this challenge by facilitating complex system of systems interactions. Examples include scaling a smart building to a smart city to an entire country, or an assembly line to a factory to a global supply chain network,” said Dan Isaacs, CTO, Digital Twin Consortium.
The seven key concepts of the DTC Digital Twin System Interoperability Framework are:
1 System-Centric Design – enables collaboration across and within disciplines—mechanical, electronic, and software—creating systems of systems within a domain and across multiple domains.
2 Model-Based Approach – with millions and billions of interconnections implemented daily, designers can codify, standardize, identify, and reuse models in various use cases in the field.
3 Holistic Information Flow – facilitates an understanding of the real world for optimal decision-making, where the “world” can be a building, utility, city, country, or other dynamic environment.
4 State-Based Interactions – the state of an entity (system) encompasses all the entity’s static and dynamic attribute values at a point in time.
5 Federated Repositories – optimal decision-making requires accessing and correlating distributed, heterogeneous information across multiple dimensions of a digital twin, spanning time and lifecycle.
6 Actionable Information – ensures that information exchanged between constituent systems enables effective action.
7 Scalable Mechanisms – ensures interoperability mechanism(s) are inherently scalable from the simplest interoperation of two systems to the interoperability of a dynamic coalition of distributed, autonomous, and heterogeneous systems within a complex and global ecosystem.
“The Digital Twin System Interoperability Framework enables USB-type compatibility and ease for all systems connected to the Internet and private networks, which until now, has been the domain of system integrators,” said Anto Budiardjo, CEO, Padi.io. “This means system integrators can concentrate on designing applications rather than point-to-point integrations.”
Interoperability has been a great benefit to consumers in many areas of the economy. Even industrial technology, where many forces coalesce to circumvent it.
I have written about interoperability specifically several times and have even given a couple of presentations on the subject. None of my work comes close to touching the work of Seth Godin and this podcast on interoperability at Akimbo.
Interoperability is great for users. The ability to connect different components and software applications powerfully enables use. However, suppliers fear that they will lose business by not being able to lock customers into their own proprietary ecosystem. Experienced users easily dismiss the argument that “all our products work better together when we control the system”. We’ve been there. That is not always the case.
The irony…interoperability is actually better for suppliers in the long run.
Check out the podcast as Seth describes indifferent, cooperative, and adversarial interoperability.
My inbox has accumulated a plethora of news about open—open standards, open source, open interoperability. Open benefits implementers (end users) because so much thought and work have been done already defining models, data, messaging, and the like that integration time and complexity can be greatly reduced. Yes, integrators remain necessary. But time to production, one of the critical measures of product success, improves. Not to mention time to trouble shoot both during startup and during operation.
Without warning a short time ago, I received a call from Alan Johnston, president (and driving force for many years) of MIMOSA. I attended MIMOSA meetings for several years and served for a year as director of marketing. I was even part of the meeting that birthed the OIIE name and fleshed out the original model. I set up a number of meetings, but we were just a little premature. We needed a bit more momentum from industry and academia to get things going. The reason for Alan’s call was that momentum was growing again. Several organizations in Australia are interested, there is renewed interest from the ISA 95 committee, and the Open O&M Initiative gained new life.
So, I wound up sitting through most of four hours of introductory meeting as the various parties—old and new—talked about what they were working on and where it all needed to go to get the job done. And Alan was right. Progress has evolved. It’s time to talk about this again.
The driving force for this work continues to be fostering interoperability and data/information flow among the major applications behind the design, construction, and operation & maintenance of a plant—engineering, operations, maintenance. Any of us who have ever searched for the current and correct information/specification of a piece of the process facing impending unplanned shutdown understand almost intuitively the critical nature of this work. (See the Solutions Architecture diagram.)
An executive summary of a white paper I wrote a few years ago still exists on my Dropbox here. The information remains relevant even though some of the organizations have changed and some technology has been updated.
The Open Industrial Interoperability Ecosystem (OIIE) enables a shift from traditional systems integration methods to standards-based interoperability in asset intensive industries, including process industries, integrated energy, aerospace and defense and other key critical infrastructure sectors.
The OIIE digital ecosystem is a supplier-neutral, industrial interoperability ecosystem, which provides a pragmatic alternative to the status quo, enabling the use of Commercial Off The Shelf (COTS) applications from multiple suppliers, as well as bespoke applications. It is defined by a standardized Industry Solutions Architecture, which enables implementations of OIIE instances for both owner/operators and their major supply chain partners that are adaptable, repeatable, scalable and sustainable at substantially lower cost than traditional methods.
The OIIE is an outgrowth of several related industry standardization activities, each of which is addressing a part of the industries requirements for standards-based interoperability. The OIIE brings these individual efforts together, with the direct participation and support of multiple participating industry standards organizations. Major parts of the OIIE include standards associated with the OpenO&M Initiative and with ISO 15926. The OIIE uses these existing standards in combination with each other, to meet the identified systems and information interoperability requirements for use cases which are defined and prioritized by the industries which are served.
Articles I have written over the years:
Standard of standards model for asset data
Plethora of Protocols
Center Industrial Internet of Things
Oil and Gas Interoperability Pilot
OpenO&M is an initiative of multiple industry standards organizations to provide a harmonized set of standards for the exchange of Operations & Maintenance (O&M) data and associated context. OpenO&M is an open, collaborative, effort composed of diverse groups of relevant organizations and subject matter experts.
The original members of OpenO&M Initiative are ISA, MESA, MIMOSA, OAGi, and the OPC Foundation. ISA for the ISA 95 standard, MESA houses B2MML, MIMOSA has CCOM among other standards, and the OPC Foundation for OPC UA.
The purpose of last week’s conference calls was to revitalize the work, introduce additional organizations, and (importantly) new and younger participants. I left the meeting with renewed optimism that the work will continue to fruition. I am personally a globalist, but as a citizen and resident of the US, I hope that our engineers wake up to the utility of standards. Most interest in general over the past several years has been found in Asia with Europe remaining strong.
Perhaps the component that holds everything together is the ISBM. This was previously described as ws-ISBM as it was based on SOAP and web services. The March 2020 update to ISBM v2.0 added REST and JSON support.
ISBM is an implementation specification for ISA-95 Message Service Model. It provides additional specificity that is required to enable two or more groups to develop implementations of the MSM that will properly interoperate with each other without a priori knowledge of each other. The ISBM provides a consistent set of specifications supporting both intra- and inter-enterprise activities, where a combination of functionality, security, supplier-neutrality and ease of implementation are required for industry digital transformation.