Implementing a Common Event Format across a Supply Chain
Supply chain management (SCM) practices are being propelled and challenged by digitalization. As increasing supply chain complexity poses new challenges, event processing (EP) and event-driven systems have established themselves in many SCM applications.
The concept of an event in SCM is admittedly confusing and open to different interpretations. Per Gartner, “business events could be anything that is noted digitally, reflecting the discovery of notable states or state changes, for example, completion of a purchase order, or an aircraft landing.” In the combined context of EP and SCM, referred to as supply chain event management (SCEM), an event is a digital representation of an object state or state change involved in a logistic process.
This digital representation comprises a data structure or format containing information about the event. As there are many types of SCM events, many event formats have evolved to accommodate them. This, in turn, has led to the rise in system complexity and middleware needed to convert and normalize information across disparate event formats.
Events are generated by event producers, transmitted via channels to be pulled by or pushed to event consumers (which can also be event producers). Event producers are devices or systems registering occurrences along the supply chain (e.g., change in a shipment’s location). Event channels are typically implemented using message-oriented middleware (MOM), and event consumers are EP systems, actuators, and users interested in product state changes along the supply chain.
Email Message for Machine-to-Human Event Notification
Users (i.e., humans) are typically notified of events via email messages. When an email message is sent, it is transported via a communication protocol (SMTP) that is understandable from machine-to-machine. In a typical example of sending an email message from a client to server machine via SMTP, the “DATA” or payload section of this message includes a human-readable, attribute-value pair data model that relays the following:
The “From” attribute value is “firstname.lastname@example.org”
The “To” attribute value is “email@example.com”
The “Date” attribute value is “1/15/15 at 4:02 PM ET”
The “Subject” attribute value is “Your Order has Shipped”
However, the body of an SMTP message (for example, ‘Hello Alice…’) is unstructured and can include URL links to related information (for example, a delivery tracking web page).
EDI Message for B2B Event Notification
As email messages enable human-to-human and machine-to-human communications, Electronic Data Interchange (EDI) messages support business-to-business communications and are used every day to exchange information objects (such as purchase orders, invoices, and advanced shipment notifications) between supply chain trading partners.
While human-readable email content (i.e. the message payload) is primarily unstructured and transported via SMTP, machine-readable EDI message payloads are highly structured and can be transported via several communication protocols including SMTP, HTTP, and an XML messaging service.
Like SMTP, EDI has been in use for multiple decades. However, EDI message payload formats have fragmented over time. In order to gain worldwide acceptance, many countries have created their own EDI formats. In the United States, the EDI standard is mostly ANSI X-12, while in the UK it is EDIFACT or TRADACOMS. They are simply delimited files, but they each have their own data model. Further, each trading partner may require a different data format and a different transport protocol to send and receive transmissions.
The data model of the EDI message includes machine-readable segments and data elements that relay the information found in a paper-based document. For example, an EDI message representing a shipment notice can include the following in its payload:
The first element in the “ST” segment (Type) is “856” (Shipment)
The third element in the “BEG” segment (PO Number) is “45678”
The second element in the “N1” segment (From) is “SmartMart”
The eighth element in the “PO1” segment (Item Number) is “98765”
A purpose-built EDI message translator app (e.g. Biztalk) typically interacts with a purpose-built business management app on a server machine to create and update business information objects that are maintained within a relational database. However, customizations to business systems add to the complexity and cost of EDI system integrations.
Fragmented M2M Event Notification
In addition to EDI, manufacturing businesses (or OEMs) are now grappling with the IoT megatrend, where the term “connected machine” extends far beyond a multi-purpose computer or smartphone to any manufactured product capable of real-time machine-to-machine (M2M) communications. These products are primarily purpose-built machines with special-purpose hardware and computing systems (embedded machines). For some consumer product manufacturers, everything they build could feed into IoT.
While EDI messages transport business information objects between cloud machines, M2M messages typically transport machine events (such as state changes) between resource-constrained, embedded machines (like a connected printer) and gateway machines using lightweight communication protocols (for example MQTT and CoAP) within a local (proximal) network. M2M messages are typically transported from gateway to cloud machines using communication protocols such as REST/HTTP and OASIS’ AMQP within a wide-area network.
With multiple communication protocols, M2M message payload formats are also very fragmented, requiring gateway machines to act as message translators between other machines. For example, a connected printer and conveyor system may utilize different M2M data protocols to communicate events such as:
The machine’s status is On
The machine’s motor speed is 10 RPM
OEMs and brands will not realize the potential of IoT until this fragmentation is properly addressed, and message translation is replaced with a common event format to communicate among embedded, gateway, and cloud machines.
Common Event Format
A common event format within SCEM enables trading partners to share information about the physical movement and status of products as they travel throughout the supply chain – from business to business and ultimately to consumers. A common format can enable disparate applications to produce and share event data, both within and across enterprises. This sharing enables trading partners to gain a shared view of physical or digital objects within a relevant business context. It also helps meet consumer and regulatory demands for accurate and detailed product information.
The Electronic Product Code Information Services (EPCIS) is a GS1 standard, originally based on RFID technology, that enables disparate applications to create and share “visibility event data” about physical or digital objects. Its primary use case has been supply chain traceability. It helps answer the “what, where, when, and why” questions to meet consumer and regulatory demands for accurate and detailed product information. However, an emerging use case is IoT and the next gen of EPCIS is in development.
EPCIS is intended to be used in conjunction with the GS1 Core Business Vocabulary (CBV) standard. The CBV provides definitions of data values (i.e., semantic identifiers) used to populate EPCIS data schemes. The use of a common vocabulary ensures interoperable data exchange by reducing the variation in how different businesses express common intent.
As an open source project within Linux Foundation, CloudEvents is evolving a common event format to provide interoperability across services, platforms and systems. In addition to ADC Technologies Group, companies contributing to CloudEvents include IBM, Microsoft, Google, Oracle, SAP, Red Hat, VMware, PayPal, Alibaba, and Huawei. CloudEvents is hosted by the Cloud Native Computing Foundation (CNCF).
An SCEM simulation was developed by IBM using the CloudEvents event format with semantic identifiers from schema.org aligned with the ACRIS Airport Semantic Model and OBEDA for plug-and-play information systems. The SCEM simulation (shown below) enables airport retailers, suppliers and freight carriers to collaborate and react in real-time to shared events.
OBEDA’s BEAMevents grid format is utilized for message payloads comprising one or more contextual events. The grid is tightly coupled to a common ontology and provides event consumers with the minimal information necessary to react to any state change occurrence. The grid includes traditional time series elements (timestamp, value, unit) and metadata identifiers for ontology elements (attribute, class and object) to support contextual events. These elements have fixed, zero-based column positions (indices) within the BEAMevents grid.
Each contextual event within the BEAMevents grid represents a state change of a single attribute, which enables one event format to be utilized across any ontology class.
To provide the ultimate customer experience requires taking the technological gains of the past couple of decades and wrapping them all up into one all-encompassing bundle of digital services. At the core, these services must provide seamless information exchange between humans and machines, and enable machines to work together to form interoperable automation systems. Today’s fragmented automation systems incorporate proprietary data and communication protocols that limit their extensibility and flexibility, resulting in complex and costly system integrations.
The emerging common event formats promise breakthroughs in achieving interoperability, portability, and configurability of connected machines, systems, and applications. A unifying interoperability standard is critical to minimize the cost and time to manufacture and implement these machines within automation systems, and to accelerate global adoption.