In the January printed issue of FE, Manufacturing News covered IIoT communication problems and resolutions in the food supply chain. FE looked at NIST’s efforts with the Open Applications Group Inc. (OAGi) to pioneer a set of communications standards for the transfer of food safety/food quality data among growers and producers, manufacturers, inspectors and regulators, shippers and consumers as reported in a blog by Nenad Ivezic, leader of the Process Engineering Group in the Systems Integration Division of the NIST (National Institute of Standards and Technology) Engineering Laboratory.

While much of the work involving the standardization of communication in the overall food supply chain is finished—thanks to help from Archer Daniels Midland, Land O’Lakes, Oracle and Boeing—there is still work needing to be done regarding the standardization of IIoT sensor data. I asked Nenad Ivezic to fill us in on the particulars.

FE: Being an engineer myself, the first thought that crossed my mind is how you get these wireless sensing devices talking the same protocols. As I understand it, you’re still working with this, correct? What is involved in setting protocols for wireless sensor devices—of which I’ve seen many at trade shows—all with different communication features (web based, text based, etc.) and APIs? How do you get the “standardization” word out to them?

Nenad Ivezic: We are focused and still working on the IIoT sensing device data exchange standards, also referred to as payload, content, document, or message standards. The other parts of a communication protocol are currently out of scope of our work, because the standards development organizations (SDOs) that we work with are focused on the payload part of the protocols, which very often is a key area of concern for business-to-business and enterprise application integration types of industrial systems integrations. With introduction of IIoT, there is even greater need to extend the enterprise level payload definitions with sensor or measurement data.

However, the payload standards also may be protocol sensitive. This means that SDOs are making extra effort to provide means for their payload standard to be readily used by a widely-adopted protocol. In case of the OAGIS standard, this is manifested, for example, in the case of the Web API protocol, where the OAGi SDO provides special capabilities to generate their payload standard to be readily included in a Web API specification.

Naturally, there is a strong social aspect, involving many organizations and stakeholders, to achieving a common protocol standard that would be widely adopted. Because for some protocols, such as Web API, such a social process has been successfully completed, the protocol stack is well-defined, leaving as a biggest remaining challenge definition of payload standards for particular usage scenarios. This is the case with OAGIS payloads enabled for Web APIs supported by NIST-developed tool (see below discussion of Score). But, in general, to get the word out about standardization, we depend on and work with SDOs and industry groups – they are the place where industry comes together to recognize and solve problems by collaborating on developing, implementing, and using standards.

FE: Sensor, production, test and quality data can also wind up in ERP systems like SAP, manufacturing execution systems, databases or Food Safety/Quality Systems. Is the work in this area basically complete or is it work in progress? What about hand-written data and COAs that vary from supplier to supplier?

Ivezic: In some cases, there are standards to allow the production, quality, and even sensor data to be included in the enterprise-level systems, such as ERP, MES, and similar. With introduction of IIoT, however, there is an unmet need to achieve integration of sensor data for enterprise-level business processes. Such enterprise-level business processes increasingly rely on data analytics, to allow manufacturing systems to respond in real time to changing demands and conditions in the plant, in the supply network, and in customer needs. Yet, presently, there is no documented standard and guideline to how such IIoT data should be conveyed to the manufacturing operation management level or the enterprise control level.

This unmet need is driving collaboration between OAGi and MIMOSA SDOs, together with NIST, to identify how an enterprise-level standard (OAGi) and plant floor-level standard (MIMOSA) may be used together to bring the IIoT data across the enterprise systems and various business processes. Similar activities are starting between OAGi and MT Connect, which is another SDO that focuses on sensor and measurement data. What NIST is trying to do in these and other cases is to help the SDOs and industry avoid the situations where existing standards are extended to cover the missing pieces without regard to the already existing capabilities in complementary standards. Instead, NIST is helping the SDOs to find optimal means to combine existing standards, where it makes sense, at an architectural level, which allows the SDOs to collaborate and to best serve their industries and adopters.

FE: You mentioned Archer Daniels Midland and Land O’Lakes being involved in OAGi. Are there any other food companies that you know of involved at this level? Are any of the food associations involved such as Grocery Manufacturers Association or Produce Marketing Association? How about retailers like Walmart or Costco? Was or is GS1 involved with OAGi with the food initiative?

Ivezic: AgGateway is an alliance partner with OAGi, and is composed of hundreds of agricultural businesses including John Deere, CNH, AGCO etc., who have been extremely active with sensor and actuators on the farm. AgGateway has a formal Traceability Work Group that initially focused on commodity harvesting and has recently expanded to a project to seed and lot identification using barcoding and OAGIS NotifyShipment JSON (ASN) during planting operations. GS1 GTIN and barcodes are leveraged during this process, and in some cases could identify product to the row level in a field depending on the model of the planter.

Previous efforts involved grain traceability from the field to grain elevators, and from grain elevators to feed and food manufacturers. Challenges within grain elevators suggested better use of and integration to process control systems and blending records management using open source historians. Bluetooth low-energy (BLE) has been piloted for transfer of commodities from container to container. AgGateway formally produced an IoT message called TransferEvent to communicate container pairings of smart edge devices and BLE beacons. AgGateway members are considering submitting this to OAGi for inclusion into the OAGIS standard.

The Traceability Work Group in the recent Annual Meeting held in New Orleans conducted a workshop to identify the linkages between the myriad of data types its members already collecting, aiming to link this data across cloud platforms. Much of this is slated to address consumer demand as identified by the Grocery Manufacturers Association (GMA) and their SmartLabel program, where the latest theme is to ‘go beyond the label.’ These linkages can identify the as-planted, as-applied (crop protection, and nutrition), as-harvested, soil health, water quality and weather data.

FE: Are the communication standards for sensor, manufacturing, test and other data being developed compatible with a blockchain system such as IBM’s Food Trust? I’m assuming data transfer into a blockchain system would be transparent, correct? (I covered IBM’s Blockchain in 2018. in Food Engineering)

Ivezic: There are a number of on-going discussions regarding Blockchain applications, with multiple vendors and universities, such as Purdue, presenting. At the previous year’s AgGateway Annual Meeting, IBM did present Food Trust capabilities. While in some cases, such as commodities where packaging is completed on the farm, there are opportunities to track through the supply chain; for grain, the grain elevator, or any point there is blending or co-mingling, the blockchain breaks down. There is no ‘silver bullet’ for these types of scenarios.

There has also been much discussion on what to put on the blockchain, specifically whether it is a full business transaction such as the NotifyShipment (ASN), or whether it is simply a hash of that transaction while still relying on other traditional B2B transactions and REST JSON APIs for inventory management use cases. The rate of adoption has been questioned, and the total cost to rural operators who may be asked to implement multiple blockchain solutions since blockchain platform interoperability has not been agreed upon.

FE: In terms of the farm-to-fork supply chain, which segments still need the most work in developing a communication system that is robust and delivers the right data to the right people who need to know?

Ivezic: First of all, Rural America broadband is still a huge problem. See the following for some hope from an OAGi and AgGateway member company: “Chairman Pai Names Members, Announces First Meeting Of Precision Agriculture Task Force.”

Second, there is no desire, other than that observed as posturing by some software vendors, for single cloud platform to house all agricultural data. Linking data residing in cloud platforms though an agreed upon approach is much more realistic than a single platform. Farmers own their data and are very sensitive to how that data is used, who accesses that data, and how it is shared.

Finally, our goal is to enable the small and medium business with the tools to capture information and provide business value through improved efficiencies. OAGi’s Quick Start program developed by the Small and Medium Enterprises (SME) work group can help farmers, as discussed with the NotifyShipment seeding use case. This Quick Start program provides the order-to-cash transactions using modern Open API Spec 3.0 specification, allowing more rapid enablement in Farm Management Information Systems, mobile applications, as farmers interact with their retail partners.

To shed a bit of light on the Quick Start program, we are all aware that Small and Medium-sized Enterprises (businesses) have had historical challenges getting ‘connected’ with their business partners to exchange electronic renditions of key business documents including purchase orders, advance ship notices and invoices. This issue has been the subject of many papers and standards initiatives promising to provide low cost solutions to SMEs. Vendor SMEs also continue to feel pressure by larger customer companies to create these connections or use web portals to receive their orders, and submit ship notices and invoices. Barriers to get connected vary, but most common issues include the lack of skilled technical resources in regional areas (rural parts of America), cost of these resources, lack of useable ERP APIs, and cost of the integration tools that enable these capabilities. Using web portals is not an effective solution for SMEs as that involves re-keying of information either into their ERP in the case of receiving purchase orders or into portals in the case of ship notices and invoices—this adds resource constraints to the SME vendor in the form of headcount or overburdened resources, which tends to introduce data entry errors.

With the advent of the Open Source software industry trend, advancement of novel service-oriented architectures, popularity and growing acceptance of business process modeling, and the creation of advanced methods and tools (see below for discussion of Score), the Open Application Group, Inc., initiated the Small and Medium Sized Business Work Group to capitalize on new capabilities. This Work Group studies and provides usable implementation guidelines for new OAGIS exchanges that allows leverage of past efforts including SIMPL-edi. A key test for this effort will be uptake of the guidelines by software vendors and their implementations within their offerings to the SMEs. NIST and OAGi, with their member companies, are planning to engage the software vendors in 2020, and are looking forward to a more optimal way of SMEs getting connected with their partners to exchange electronic documents.

FE: What do you see for the future of wireless IoT devices in the food supply chain?

Ivezic: Standards will play increasingly important role in making the IIoT devices readily integrated and the IIoT data used at all levels of the food enterprise and supply chain. As described in an earlier answer to your questions, payload standards will continue to be a key and most challenging part of the standardization. ‘Nailing down’ precise intent and meaning of the payloads that are being captured through IIoT devices at multiple levels of the food enterprise and intertwined supply chains of many companies is a particularly challenging task. There are two major challenges that need to be addressed, as discussed next.

Across the distributed farms, IIoT and other sensors are becoming rapidly deployed, currently collecting commodity moisture, protein, weights and other measurements. AgGateway originated standards for water irrigation flow rates are already approved by ISO and making their way into products. There is an increasing desire to push more capabilities to the field such as sensors to determine soil and plant health instead of sending samples to laboratories for analysis.

Now, in the traditional enterprise data integration architecture, measurement data is contextualized incrementally as it percolates up the hierarchy. This data is usually maintained within the applications that originally acquires it. On the other hand, in the IIoT enabled distributed paradigm, IIoT data needs to be shared and accessible instantly across the functional hierarchy. Therefore, appropriate context data needs to be immediately attached to IIoT data and ubiquitously accessible to all.

This brings us to the first challenge: to resolve the issue of contextualization of sensor and measurement data to enable their accurate and timely use across the enterprise and at multiple levels. This is important in order to understand the asset collecting the data, its location, its last calibration date, and usage. In the future, the IIoT data will need to be annotated, probably automatically, with the contextual information that precisely indicate time, operation, job, asset, location, business process, and other important meta-data that makes the IIoT data readily usable. Exactly how this will be accomplished is a topic of our research that needs to be performed in the laboratory and in the field. Also, analogies of farm operations to manufacturing operations suggest there are opportunities to leverage other standards that have addressed these concerns.

Another major challenge is to advance efficiencies and quality of, what we call, life cycle management of standards, including the IIoT standards. In the future, creation and use of the standards will be a much faster affair then today, thanks to the new generation of tools and methods, such as the Score tool, created collaboratively by NIST and OAGi. Score uses an advanced knowledge-intensive approach that provides a new standards development language and enables a new standards-focused method. The tool is shown to effectively address the difficult issues of implementation-dependency and complexity of standards in practice today. It is proven to enable more precise and more efficient data standards development and use. Research and development is ongoing to make the tool widely usable in all stages of standards development and use.

These and other research and development challenges are topics of collaboration between NIST, OAGi, AgGateway, and other standards development organizations dedicated to enabling new IIoT-driven capabilities for the food enterprise and supply chain.

We would like to acknowledge all those who played an active role in helping to develop the new specification.

NIST:

• Nenad Ivezic,
• Boonserm Kulvatunyou,
• Yan Lu,
• Evan Wallace,
• Frank Riddick

UMBC (University of Maryland, Baltimore County); and Guest researcher at NIST

• Hakju Oh

University of Macedonia, Greece; and Guest researcher at NIST

• Athanasios Dimitriadis

OAGi:

• Jim Wilson (also, AgGateway)
• Michael Figura
• David Connelly

Land O’ Lakes:

• Scott Nieman

Oracle:

• Michael Rowell
• Garret Minakawa

Boeing:

• Jeff Rice
• Kevin Himka

Lockheed Martin:

• Jaime Wightman

ADP:

• Steffen Fohn

About Nenad Ivezic

Dr. Nenad Ivezic is a research staff member of Systems Integration Division (SID) in the Engineering Laboratory (EL) at the National Institute of Standards and Technology (NIST). Dr. Ivezic works on measurement science problems that typically lead to new testing methods and standards required to solve challenging technical problems in advanced manufacturing systems.

Ivezic leads projects that investigate advanced technologies for systems integration, semantic technologies, standardization, and testing. Some of the recent projects he initiated include Global Testing Network project, Supplier Discovery in Dynamically-Formed Supply Chains, Production Network Supplier Characterization, Manufacturing Network Service Models, and Smart Manufacturing Reference Architecture.

Dr. Ivezic has been a long-time contributor to the Automotive Industry Action Group (AIAG) where he developed testing methods and standards for material replenishment and logistics processes. He is a two-time recipient (2006 and 2007) of the annual Automotive Industry Action Group (AIAG) Outstanding Achievement Award. Nenad has been a long-time contributor to the Open Applications Group, where he lead development of the Business-to-Business Interoperability Testbed to commercial B2B software solutions to assure conformance to application standards and also co-chaired OAGi Semantic Integration Group. He is a recipient (2013) of the OAGi Outstanding Contributor Award.

Nenad extensively publishes on topics ranging from interoperability, advanced manufacturing, to testing, and standardization. He has been on international program committees of the Interoperability for Enterprise Systems and Applications Conference (I-ESA) since 2006 and the e-Challenges Conference from 2005-2012. He was the Chair of the Global Interoperability e-Business Test Bed (GITB) CEN Workshop and contributor to the development of the ebXML Business Process Catalog within the Un/CEFACT standard development organization.

Before joining NIST, he was a Senior Researcher at Oak Ridge National Laboratory, where he worked on research problems at the intersection of manufacturing and information technologies and for which he was awarded three patents.