ebbits: Enabling traceability in meat production

Figure 95. The lifecycle of pork meat product (Udsen et al., 2010)

In the ebbits project, several approaches to enable product traceability were investigated in order to improve transparency of the products for the customers. Moreover, traceability is useful when a product is found defected and need to be recalled. Having the possibility to trace the origin and distribution of the product electronically reduces the time required to isolate the potential problems and recall the products that are sold on the shelves. To enable a traceability along the supply chain network an uniform identification scheme must be used, and related product IDs must be linked (e.g., The id of the cow is linked to its meat). Furthermore, the production data must be collected, aggregated, and made available to the

parties that are authorized to retrieve the information about the products. The traceability scenario in ebbits describes the potential of IoT technologies to collect information from “farms to fork” and made them available for actors along the chain. Figure 95 shows an example of meat production processes in the pork meat industry. The production is started in a farm where pigs are born and raised with their mother until they reach a certain age where they are able to eat industrialized feed. The pigs are then moved to another location or farm, in which they are fed with livestock feed until they reach a certain weight.

When the pigs have reached a certain weight, they are sent to abattoirs. In the abattoirs, their information is recorded into the abattoirs’ ERP system. Once they are slaughtered, depending on the customer request, the carcasses are cut into smaller pieces which then are put into packages and labeled with barcodes. The packages are organized on pallets then delivered to wholesalers, retailers, or restaurants. A few supermarkets in Germany have provided an additional QR code that can be used by the customers to retrieve traceability information such as the location of the abattoirs. However, more detailed information that can be obtained by applying IoT technologies are not yet available such as how much carbon footprint is required to produce the meat, whether the pigs were fed with organic food, etc.

The pigs are not tagged with any RFID at the moment, since the technology is still too expensive in relation to the price of pork meat, some farms however use tattoo branding. Only the sows are tagged with RFID since the farms in Europe are required to know the ancestry information. The regulatory requirements differ from country to country. On the farm, the health and feed information about the pigs are recorded in a farm management system. However, these feeds and medical information is usually applied in batches. That means if a pig is ill; the whole pigs in the same pen will be treated with the same medication.

The main challenge of enabling traceability on a meat production chain is, the interoperability within the organization and between external organizations must be achieved. It requires the slaughterhouse, distributors, and retailers to be able to collect data internally from different subsystems, as well as tracking information along the chain to the farms. The farms must be able to trace the feed and medicine that have been given to the pigs to be able to localize the problem when it arises. Moreover, they need to keep a record of the distribution to be able to recall the affected meat.

Collecting and tracking these chain of information requires a seamless communication between devices and software in the local sites where information about the livestock or the meat is collected as well as seamless communication between organizations involved in the production chain. The main issue for enabling a seamless communication is the existence of heterogeneous systems within the organizations and between the organizations. There exist no well-established standard which regulates how these different information systems should share their data. On the farm level, there exist different suppliers of feeding systems, climate controls, and farm management, on modern slaughterhouses usually a more standardized industrial automation system connected to an ERP system is used to keep track the meat production. The data from the farms are often handed over to the logistic companies through forms and papers. This information is handed over to the slaughterhouses, then entered manually into their system. There is different information that could be included in the end product. For instance, since there is not a consistent standard of organic farming, the consumers might not know the quality of feed, whether antibiotic and hormone are used for

147

growing the livestock. The consumers who have more environmental conciseness may want to know the emission produced in transporting the meat. Moreover, the modern logistic vehicles are able to keep track the temperature of the meat during the transport to ensure that the cold chain is not violated, and the meat shelve life is consistent. When the animals arrived at the slaughterhouse, they are checked by veterinarians then slaughtered. The slaughterhouse usually assesses the meat quality in terms of fat contains and add this information for the retailers.

A proposed approach in ebbits (Brizzi et al., 2013) utilizes a centralized application which retrieves information from different stakeholders along the production chain. To enable the communication between the central application and various systems used by the stakeholders, bridging applications must be built which are responsible for collecting the input from each system using the required protocols and data format and transform this into a uniform protocol and data format which is able to be understood by the central application.

In ebbits project, a simulation of a beef production chain was implemented to demonstrate the proposed solution. In this demo, a beef production was chosen since most countries have required that cattle must be individually tagged, which makes the solution more realistic to be implemented. The flow of the data along the production chain is depicted in Figure 96. Along the chain, the cattle are represented by DigiCows which are software objects that are interlinked. When they have been slaughtered, they are represented by Bulk Beef that are linked with the DigiCow that represents its origin. In this demo, the cows were simulated using RFID tags which were scanned using RFID readers on each stakeholder. The data on the farm such as the weight of the cows and the amount of feed are simulated through physical sensors connected to Arduino boards.

The initial implementation done without specific tools except for Java and C# programming. The efforts required for the development were approximately 1.5 months of work done by two developers with 75% time for the project.

Farm management system Farm Sensor DigiCow Transport Slaughter Transport Retail Transport Consumer Fridge Consumer App Processor App Simulation Time/Distance RFID with sensor Quality Method Time stamp Weight DigiCow DigiCow (Digi)Bul k Beef Bulk Beef Bulk Beef Bulk Beef Bulk Beef Bulk Beef Beef (Digi)Beef Beef Beef Recall App

Figure 96. The data acquisition for enabling traceability in meat production through the ebbits platform (Madsen et al., 2013).

Replicating this development, IoTLink was used to capture the DigiCow and BulkBeef that are sent from one stakeholder to the next one and expose this information to the interested stakeholder in the production chain through different network protocols. On the farm, the each DigiCow must be correlated with the feed object that is consumed by the cattle. To log the feed consumed by the cattle, an RFID reader and two scales to weigh the feed and the cow could be installed. In ebbits, these devices were simulated using Arduino boards that are connected to an RFID reader and digital scales. When a cow approaches the feeding station, its tag, the feed id, the amount of the feed consumed by the cattle, the weight of the cattle are published through an MQTT broker through the Arduino proxies. In this case, the cow was simulated through RFID tags. The amount of feed was simulated through the data delivered from the scale connected to the Arduino. IoTLink was used to generate an application that captures these events and log them into a database.

Figure 97. Domain model for recording livestock feed.

As illustrated in the Figure 97, to log the feeding events from all cows, the cows were considered as moving objects that have dynamic relations to the sensors attached to the feeding stations therefore we only need to have a DigiCow with the type of Moving Object at each feeding station. Since the prototype application only needs to log the feeding events, we do not need to model the stations.

149

Each time a cow feeds at the feeding station, the generated application retrieves the corresponding DigiCow from the VirtualObjectFactory. When the factory could not find the corresponding virtual object, it creates a new virtual object to represent the cow. However, when the object containing the id of the cow already exist, the factory retrieves that object and hand it over to the MainApp where its properties are updated with the data coming from the sensors and sensor fusion modules.

Using a simulated data, the feeding station data is published through an event generator. The DigiCow objects are stored in a memory as well as MySQL database. When the DigiCow objects are updated, e.g., their weight has increased, before they are updated, the history is stored in MySQL database. The DigiCow objects are published through a REST-based service which follows the structure of the domain model as depicted in Figure 98 on the left side. On the right side, the link to each DigiCow object is encoded in QRCode which can be used to tag the physical cow right before it is sent to the slaughterhouse.

The efforts required for the development with IoTLink was approximately 2.5 weeks of work done by two developers with 75% time for the project.

Figure 98. DigiCow database which is accessible through REST (left) and generated link encoded in QRCode (right)

7.2.3 BEMOCOFRA: Monitoring a flexible manufacturing