Keywords

Introduction

Studies show that temperatures during supply chain activities often differ from the ones recommended by the producer, which might result in shorter durability of perishables, such as dairy products, fresh meat, and fish (Likar and Jevšnik 2006). Thereby the specified expiry datesFootnote 1 are no longer valid. On the other hand, food that has been well treated can often be safely consumed after the expiry date has passed. It has been estimated that one third of all food produced globally for human consumption is lost or wasted (Gustavsson et al. 2011). Jedermann et al. (2009) state that among environmental parameters during transport, temperature has the most significant influence on the quality of food products. Studies furthermore show significant temperature variations inside a vehicle as well as during storage (Moureh and Flick 2004).

To prevent people from discarding food still suitable for human consumption, as well as to ensure the quality of the expiry dates, information about the actual conditions during the supply chain activities are needed. By using local sensors to measure the environmental conditions, such as the temperature, the quality of each individual product can be estimated. These sensors must be present throughout the transport chain, and the closer to the products they are placed, the more accurate estimations can be made. Based on the estimated quality, the expiry dates can be updated continuously enabling actors within supply chain management as well as the final consumers, to make more informed decisions about how to handle the food and when to discard it. Furthermore, a dynamic expiry date service might be colligated with other services such as tracking and tracing, product information (for instance origin and handling instructions), carbon dioxide labeling, and dynamic pricing based on currently estimated expiry date (Bartels et al. 2010).

The aim of the paper is to present and apply a novel approach for how to select the most suitable system architecture for a service providing dynamic expiry dates of perishable food. The approach consists of three steps:

  1. 1.

    Identify all potential system architecture candidates based on a new system architecture representation model.

  2. 2.

    Filter out the least relevant candidates by applying a specified set of principles.

  3. 3.

    Perform an AHP based on a set of quality attributes to determine which architecture is the most suitable.

The approach is used to analyze all architectures satisfying the requirements of one particular user group, the supply chain managers, in order to select the most suitable architecture. The architectures differ in the intelligence required at product-level, vehicle/terminal level, mobile terminal level, and central level.

Related Work

Concepts implying a higher level of intelligence related to the product itself, in comparison to only possessing an associated ID, are often referred to “smart” or “intelligent,” such as “Intelligent Goods,” “Smart Goods,” or “Intelligent Products” (Meyer et al. 2009). Depending on the level of intelligence, these concepts can be applied for monitoring the local conditions during transportation (López et al. 2011), and maybe for calculating a dynamic expiry date. The intelligence related to a product may or may not be located on the product itself (Meyer et al. 2009). However, for the dynamic expiry date service, local intelligence, for instance implemented on the product, a pallet or in the vehicle, able to perform condition monitoring is required.

Within the area of communicative packaging, potential means to monitor the condition of packaged contents by enhancing the intelligence of the package itself have been investigated. The solutions consist of a combination of packaging technologies and communicative signals (e.g., changing colors, diagrams, displays) (Dobon et al. 2011). Communicative packaging is seen as a specific type of smart packaging, which uses different technologies to add extra features to packaging (e.g. information about expiry date, identification about the type/origin of the product and protection against counterfeiting). A life-cycle assessment study on the use of a flexible best-before-date communicative device (FBBD, with a temperature logger and a display) on packaging consumer units, shows that the use of FBBD devices decreases environmental burdens associated to the production, packaging, and delivery to the point of sale, thanks to reduction in food losses (Dobon et al. 2011). Other case studies show potential benefits of radio-frequency identification (RFID)-based cold-chain monitoring in increased sales due to reduced out-of-stock, reduction in inventory due to lower safety stock, improvement of visibility and transparency in the supply chain etc. (Jol et al. 2006). Benefits from using time temperature indicators (TTIs) have also been investigated (Sahin et al. 2007; Bhushan and Gummaraju 2002). An alternative to enhancing the package of a product itself is to place the local intelligence, including temperature sensors, on a higher level, for instance on containers or in vehicles (Ruiz-Garcia et al. 2007). A discussion about different degrees of decision freedom that may be dedicated to products as well as commonly used applications on different hardware layers can be found in Jedermann and Lang (2008). Placing intelligence on different levels in the transport system results in different processing, information, and communication requirements as well as enables different service qualities and functionalities. Depending on the purpose of local condition monitoring and expiry date estimations, different solutions based on different system architectures might thereby be preferred—in particular by different target user groups. To the best of our knowledge, no previous study has identified these system architectures and investigated the differences between them, with respect to the issues above.

Methodology and Service Description

In order to be able to compare different system architectures of the dynamic expiry date service, they must first be identified and characterized. We identify the potential architectures by first specifying all activities (A) that must be performed, as well as the different locations (L) where each of these activities could be performed. By combining the activities with the locations we get the set of all potential architectures (i.e., the Cartesian product LǀAǀ). This set is then reduced by filtering out impossible and obviously impractical architectures. From the remaining set of architectures, the most suitable ones, with respect to the functional and quality requirements of each target user group, shall be found. Ideally, every identified architecture should be evaluated and compared. However, due to the amount of work this process would require, the least suitable ones are filtered out in two steps. First, all solutions possible for each user group are identified based on some prerequisites regarding how the expiry date should be presented. In this paper, we only focus on the architectures satisfying the requirements of the supply chain managers. Second, heuristics derived from general requirements on the architecture are applied to identify the most promising candidates. Finally, an AHP is performed on the resulting set of architectures, prioritizing the most suitable ones according to a set of quality-based criteria. AHP is a method for analyzing complex decision problems with multiple criteria (Saaty 1980).

Input to the dynamic expiry date service is Goods-ID (the unique ID of a product, e.g. SGTIN) and output is the expiry date. In this study, we assume that the calculation of expiry date is based on sensor data related to the condition of the product, including both current and historical data, for instance temperature values. Thus, a local sensor is needed to sense and record the local conditions according to some time interval, and the stored sensor data must be possible to read. Theoretically, the service could have been based on measuring the current bacteria level only, without regard to any historical data. However, given the current status of sensor technology, direct and possibly automated measurement of the current bacteria level in a product is not a viable approach. The Goods-ID is assumed to be stored at product level, making all products electronically identifiable.

The System Architecture Representation Model

The expiry date service requires the execution of four main activities: (a 1) the local conditions of the product have to be measured, (a 2) the recorded sensor data must be stored, (a 3) the expiry date must be calculated based on the stored sensor data, and (a 4) the result must be presented to the user of the service. These activities (A = {a 1, a 2, a 3, a 4}) can be located: at product level (P), on a fixed local device (N), on a mobile local device (M), in a remote device (R) or in the cloud (C), i.e. L = {P, N, M, R, C}. Below, a more detailed explanation of the different locations is given, whereas Fig. 1 illustrates the corresponding possible communication links. In this study, we assume that both R and M are connected with the cloud (when there is coverage) and that N is available whenever needed in accordance with the requirements of the architecture.

Fig. 1
figure 1

Possible communication links between different parts of the service system, (W)WAN (wireless) wide area network, WPAN wireless personal area network

Full size image

P: Entity at product level, e.g., attached to the primary package, secondary package or a pallet. This entity follows the product throughout the transport.

N: Fixed local device near the products, located for instance inside a vehicle, a terminal, or a refrigerator. The N used by the service on behalf of a product may change during transport, when the product is moved.

M: Mobile local device near the products, for instance a mobile phone provided with an app or an RFID reader. Consumers and local supply chain personnel (e.g. drivers and terminal workers) may employ such a device. M communicates with N and P directly, via RFID or WPAN (Wireless Personal Area Network). For instance, M may read the Goods-ID from the product and then retrieve the corresponding expiry date from C.

R: Remote device, for instance, a stationary computer running an ERP system. R is unable to communicate directly with N and P but communicates through the cloud instead.

C: Cloud-based entity, for instance a network server, accessible from any device with Internet access.

The set of potential architectures, LǀAǀ, consists of 625 elements of which some correspond to architectures that are impossible or obviously impractical. Measuring the local conditions in C or R is impossible, and to do it on M is impractical since M may be moved around. Also, to store the sensor data on M or N is impractical since the service should not be dependent on M being present (receiving sensor data via WPAN/RFID) and since storing sensor data on N would require a data transfer whenever N changes and that might not be possible (or desirable for security reasons). Finally, to present the expiration date in C is not meaningful. To sum up, the activities may be executed in the following locations in the system:

  1. 1.

    Measurement of local conditions: P or N

  2. 2.

    Sensor data storage: P, C or R

  3. 3.

    Calculation of estimated expiry date: P, N, M, R or C

  4. 4.

    Presentation of expiry date: P, N, M, or R

The calculated expiry dates are assumed to be stored either where they are calculated or where they are to be presented in the system. The calculation of the expiry date is based on current and historical sensor data and this sensor data might, on the other hand, be stored somewhere apart from where it is collected or used. The reason for storing this data in a third place might be to avoid overloading the product level or to allow for the fixed local device to be changed during transport. Depending on where the sensor data is stored, a higher level of intelligence might be required by the involved entities, as well as additional communication.

The filtration above results in 120 different alternative architectures (2 × 5 × 4 × 3 = 120). We have investigated each one of them with respect to individual characteristics, usefulness for different target user groups, communication paths and required capabilities (according to Jevinger et al. (2011)). Additionally, the set of architectures has been further extended to also incorporate different alternatives for long distance communication between P and C/R (resulting in 186 architectures), since this in some cases introduces additional entities and capability requirements. Long distance communication between P and C/R can be performed using a direct link, or by transmission via N or M. In this paper, we assume that P does not communicate directly with C/R, but only through N/M. The reason for this assumption is that the most reasonable solution considering today’s technology, is to use short distance wireless communication to N/M and let N/M be responsible for the long distance communication.

The architectures can be grouped based on where measurement, storage, and calculation are located. All architectures with the same locations of these activities only differ in where the expiry date is presented, and they may therefore be combined to provide several means of accessing the expiry date. For instance, a solution showing the expiry date in both the R and M might be required (e.g. to satisfy requirements from drivers and terminal workers as well as centralized supply chain managers), based on architectures with the same locations of the other service activities (measurement, storage and calculation). In this study, we show an approach for how to prioritize and select the most suitable solutions for one of the target user groups; however, this approach can be used to prioritize the solutions for other user groups as well. If a combination is required as described, the topmost architectures with the same locations of measurement, storage, and calculation should be selected from the resulting prioritized lists of architectures.

Heuristics

Different user groups require different alternatives for how the expiry date should be accessed. This paper focuses on supply chain managers and we assume they will read the date in a remote device (R). Ideally, all architectures fulfilling this requirement should be evaluated with respect to the functional and quality preferences of the supply chain managers. This would mean evaluating 48 architectures. For other user groups identified, the set of architectures to evaluate result in 138 architectures, and performing an AHP on all of these would require a huge amount of work. Moreover, many of the architectures that are possible from a theoretical perspective reflect solutions that do not seem reasonable from a practical perspective, such as calculating the expiry date in M and showing the result on P. Therefore, we have developed two principles for filtering out the least promising architectures, from the perspective of the supply chain managers. The list of principles may have to be extended for other user groups, though the principles below should be applied for those as well.

Principle 1: If sensor data is stored on C/R and the expiry date is presented on R, the calculation should be co-located with the storage or the presentation. The purpose of this principle is to prioritize the simplest solutions that do not involve sending information back and forth, in particular from the central level, to the local level, and back again. For instance, architectures storing sensor data in R, using P/N for calculation, and showing the resulting expiry date in R, are removed. This principle filters out the following architectures (Measurement-Storage-Calculation-Presentation): P-C-P-R, N-C-P-R, P-C-N-R, N-C-N-R, P-C-M-R, N-C-M-R, P-R-M-R, N-R-M-R, P-R-C-R, N-R-C-R, P-R-N-R, N-R-N-R, P-R-P-R, N-R-P-R.

Principle 2: Architectures showing the expiry date on R shall not use M for calculation. The supply chain managers should not be dependent on M for receiving the expiry date since M is mobile and is therefore not guaranteed to always be present. This principle filters out the following architectures: P-P-M-R, N-P-M-R.

As a result, 14 candidates have not been rejected by the principles and are thus subjects for AHP analysis. The choice of where to measure the local conditions (P or N) depends on the temperature variations between N and the product, but also on how sensitive the product is to measurement errors. Based on the properties and shelf life model of a specific product, architecture candidates measuring the conditions on N may in some cases be filtered out. In this paper, we assume relatively insensitive products in order not to narrow the analysis more than necessary.

AHP Analysis

AHP is an approach for selecting the best from a number of alternatives, which are evaluated with respect to several criteria. Pairwise comparisons are used to develop overall priorities reflecting the importance of each criterion, relative to the goal of the selection problem. The performance of each alternative on each criterion must also be determined, and together with the priorities of the criteria, a ranking of the alternatives can be produced. AHP has previously been successfully used for evaluating architecture candidates (Svahnberg et al. 2003). As a first step, the set of criteria must be selected. We have identified the quality attributes listed in Table 1, as relevant for the dynamic shelf expiration date service.

Table 1 Criteria for AHP analysis
Full size table

The second step of AHP involves prioritizing the criteria according the importance of each criterion, in relation to the goal of the selection problem. Each criterion is pairwise compared to all other criteria with respect to how desired they are to the service system. These comparisons are based on interviews with three actors within the food supply chain. We only use consistent priorities, and after the pairwise comparisons, the priorities are normalized to sum up to one. The resulting priorities from the interviews are listed in the first row of Table 2.

Table 2 Priorities derived from interviews and comparisons between the architecture candidates with respect to the criteria as well as the final results of the AHP analysis
Full size table

In the third step of AHP, the architecture candidates are compared with all other candidates, with respect to the criteria. These comparisons are based on pairwise subjective assessments and as before, we use consistent priorities, normalized to sum up to one. The resulting sets are shown in Table 2.

In the fourth step, the relative importance of each criterion is combined with how well each architecture candidate satisfy the criteria, by multiplying the normalized priorities related to the architecture candidates with the normalized priorities of the criteria. The resulting products are thereafter summed for each architecture candidate and the values of these sums reflect the suitability of each candidate, in relation to the other candidates. The final values for each architecture candidate are presented in the last column of Table 2.

Table 2 shows that, with this approach, architecture N-R-R-R receives the highest priority for the supply chain managers, with respect to quality and functionality requirements. Architectures N-C-R-R and N-C-C-R are similar and regarded as second best. Taking into consideration the costs of each solution as well naturally would change the order of priorities. For instance, architecture P-R-R-R most probably entails a higher cost than architecture N-P-R-R, since architecture P-R-R-R requires sensor capability on P whereas architecture N-P-R-R may be implemented using a simple read/write passive RFID tag on P. Implementing a high level of intelligence in product-level devices is usually relatively costly since the number of products is high in relation to the other potential locations, for instance vehicles. Thereby, the approach presented in this paper shall primarily be used for prioritizing the architectures from a functional and quality perspective, and based on these results, in combination with the costs of each architecture candidate, the most suitable solution can be selected.

Conclusions and Future Work

We have shown a novel approach for how to identify the most suitable system architectures of an expiry date service. The approach is illustrated by focusing on one user group, the supply chain managers. Apart from the analytical desktop work, the selection process also incorporates interviews with three actors within the food supply chain, affecting how different qualities should be valued.

In order to be able to list all architectures we have developed a representation model, which is used to characterize the architectures based on where the different activities involved in the service are located. The primary advantages with this approach are that all possibilities can be identified and evaluated. Thereafter, we have used user group requirements and heuristics to filter out architecture candidates that reflect the general requirements on the final solution. The candidates have been evaluated in an AHP based on a number of quality criteria, and the results are presented as a list of priorities of the candidates.

In this study, we have assumed N is available whenever needed. In reality, this might not always be the case. Architectures in which N is only available during certain parts of the transport, sensor data might only be possible to transmit at arrival to the terminals, produce other values of the quality criteria. A more concrete situation would reveal the alternative locations of N and taking these locations into consideration as well would expand the set of architecture alternatives. This paper is focused on the fundamental solutions and if other varieties need to be evaluated, the approach presented in this paper may be used for these as well.

Once the solutions satisfying the functional and quality requirements have been identified, they should be analyzed with respect to their costs, in order to determine the ideal solution. We plan to consider the costs in a second paper, by performing a cost–benefit analysis on the set of architecture candidates resulting from this paper. The environmental impacts of each architecture will also be considered in the AHP criteria. Furthermore, the second paper will describe a pilot study implementing a number of architecture candidates, and the measured values from this study will be used in an additional AHP.