Security, safety, and compliance of a supply chain process and involved assets are critical to any organization. Supply chain participants want to be sure that assets sent to another party are treated correctly and that assets received from another party can be trusted. For example, supply chain participants want to be sure that the received purchase order data and the payment data are correct, and that the ordered goods have been treated according to various requirements. Moreover, many enterprises today need to comply with regulations As many enterprises need to comply with various regulations such as Basel II or the Health Insurance Portability and Accountability Act (HIPAA), there is a strong demand to specify and communicate security and safety requirements on the level of the supply chain models. In this way, each of the supply chain participants is able to explicitly specify taken security and safety measures to other partners, and can see measures taken by the other partners. A supply chain model can be used as the basis for automation of supply chain execution, as well as for communication between the different stakeholders. Security and safety requirements, as well as implemented protective measures included in the supply chain model can be used as contract agreement between the participants.
The above picture gives an overview of the developed approach. We extended traditional business process modeling environment (for prototype we used Microsoft Workflow Foundation, which contains constructs similar to BPEL) with explicit notion of a business process asset. We distinguish between the logical assets, which are virtual objects represented through the digital data, and physical assets, which are the real world objects. We added a number of tags that can be used to classify the assets used in a process. For example, a logical asset can be classified as “private data” or “financial data”, while a physical asset can be classified as “milk product”. A user can attach any number of tags to any asset. Examples of logical and physical asset tags can be seen in the left table below.
RiskDB contains a number of rules derived from various standards that describe potential threats for each asset classification. For example, “private data” has a threat of being exposed, “financial data” has a threat of unauthorized modification, while a “milk product” has a threat of being spoilt. In addition, RiskDB stores a number of controls that can be applied at specific execution points of an activity to prevent or detect occurrence of identified threats. For example, private data can be encrypted prior to sending, financial data can be digitally signed after creation and verified prior to processing to detect unauthorized modifications, and temperature sensor can be installed to detect decay of a milk product. At the design time, the user needs to classify each supply chain asset by adding applicable tags to the asset. When an asset is assigned to an activity, a query is sent to the RiskDB to identify potential threats and applicable counter measures for this asset based on the tags assigned to the asset and on the type of activity that uses the asset. The user can then choose one of the suggested controls and apply it at the identified control point: before activity execution (e.g. signature verification), after activity execution (e.g. signing of a document), or during activity execution (e.g. temperature monitor). Right table shows some example controls for logical and physical assets.
In the above screenshot we can see a signature control applied at the output control point to the financial document PurchaseOrder in the first Order activity, which is executed by REWE. The PurchaseOrder documant is then sent to EisBaer and is processed by Dispatch activity. Here we can see application of a signature verification control at the input control point, which checks that the PurchaseOrder has not been modified after it has been signed. Finally, in the Transport activity executed by BaaM we can see application of two physical controls at the internal control point: light control measures the light conditions during transportation using light sensor and verifies that they are within specified limits, while location control uses GPS location to verify that the chosen route corresponds to the one defined in the model.
At runtime, specified controls are mapped to the invocation of the corresponding control services, such as signature service or sensor service. The states of the assets and control service invocation results are logged, and control violations are reported to the user. In the screenshot we can a simulated execution of the modeled supply chain. The highlighted transport activity indicates the current position of the supply chain execution. We can see violation of the light control signaled through the red traffic light in the monitoring dashboard. The current good position and the taken route is displayed on the map on the right hand side.
Thanks a lot for your time and hope you enjoyed this short introduction!