AUTHOR(S) CLIENT(S) CLASS. THIS PAGE ISBN PROJECT NO. NO. OF PAGES/APPENDICES

Transcription

1 SINTEF REPORT TITLE SINTEF Fisheries and Aquaculture Aquaculture Technology Address: NO-7465 Trondheim, Norway Location: SINTEF Sealab Brattørkaia 17B Telephone: Fax: Internet: Enterprise No.: NO MVA Alternative directions for standardised traceability information exchange AUTHOR(S) Eskil Forås, Gunnar Senneset, Finn Olav Bjørnson, (SFH) Geir Vevle, (Nortura) Roger Midtstraum, (NTNU) Øyvind-Harald Bolstad, (NSS) CLIENT(S) Pelagisk forum, KMB Lønnsom foredling, Innovasjon Norge REPORT NO. CLASSIFICATION CLIENTS REF. SFH 80 A Open CLASS. THIS PAGE ISBN PROJECT NO. NO. OF PAGES/APPENDICES Open /9 ELECTRONIC FILE CODE PROJECT MANAGER (NAME, SIGN.) CHECKED BY (NAME, SIGN.) Master Rapport STIE Dubrovnik.pdf Eskil Forås Carl Fredrik Sørensen FILE CODE DATE APPROVED BY (NAME, POSITION, SIGN.) Jostein Størøy, Research director ABSTRACT The aim of this report is to analyse and recommend on alternative directions for standardised traceability information exchange. The following observation has been made on how traceability information exchange is be related to existing B2B information exchange: Traceability information and B2B information are strongly interrelated by being created and consumed within the same business processes. This observation suggests that: Traceability information should not be managed independently from other B2B information. Traceability information and B2B information should be exchanged through the same mechanisms. Existing information exchange standards have been analysed regarding their applicability to include traceability information. Based on this analysis, recommendations whether these standards are applicable or if there is need for further work to enable traceability information exchange have been worked out. The conclusion is that there are two open standards that are applicable for information exchange. The TraceCore XML, which has previously been used for exchanging traceability information, and the generic Universal Business Language (UBL) from OASIS. A comparative analysis shows that the UBL almost completely includes/overlaps TraceCore XML. Thus, this work recommends to use available UBL documents and to eventually form a subcommittee to expand the current standard or to establish a recognized traceability customization of the UBL. KEYWORDS ENGLISH NORWEGIAN GROUP 1 Food traceability Sporbarhet GROUP 2 Information exchange Informasjonsutveksling SELECTED BY AUTHOR XML XML Standard Standard

2 2 TABLE OF CONTENTS Alternative directions for standardised traceability information exchange Introduction Traceability information Traceability information exchange versus existing B2B information exchange Supply chain information (B2B) exchange Traceability information exchange in supply chains Use of traceability information Traceability information analysis Relevant electronic information exchange standards UBL The Instrumentation, Systems, and Automation Society (ISA) TraceCore XML Traceability of the swine value chain (P2P) Analysis of these standards regarding combining regular B2B information with traceability information Comparing TCX and UBL UBL vs. TCX with regards to Traceability UBL vs. TCX with regards to B2B Conclusion and future work Appendices...16 Reference...16

3 3 1 Introduction In the European food industry today, electronic exchange is regarded as the most applicable and effective method of traceability information transmission (Ubieta 2006); (Bello, Mirabella et al. 2004; Senneset, Forås et al. 2007). Several publications on chain traceability data management in the food industry have pointed out the need to improve electronic data exchange (FSA 2002), (Bechini, Cimino et al. 2005); (Garuti 2005); (Folinas, Manikas et al. 2006). Different projects are developing generic standards for electronic exchange of traceability information (Garuti 2005; TRACE 2006; Tracefood.org 2007). In addition there are existing standards for general business to business (B2B) information exchange 1 and enterprise control integration 2 (Johnsson 2006). There is a high activity in Norwegian on R&D projects with focus on electronic traceability in the food industry. Some of these projects are listed below. 1. Developing electronic traceability based on TraceCore XML in the Pelagic fish industry Competitive Food Processing in Norway InnovaRFID e-traceability TraceFish implementation in the Norwegian seafood industry (TRAINS) Common tasks in these projects are to Develop sector specific prototypes based on standards for information exchange Implement and test the sector specific prototypes Projects 1 and 2 will in addition analyse and recommend existing standards for information and traceability information exchange between different software applications. The objective of this report is firstly to analyse and give recommendations on how traceability information exchange should be related to existing B2B information exchange. Secondarily to analyse existing information exchange standards regarding their possibility to include traceability information. The third step will, based on results in step one and two, give recommendations whether the standards may be applicable or if there is need for further work to enable traceability information exchange. SINTEF Fisheries and Aquaculture has made a literature study of published work on "electronic food traceability" and organized a workshop on" traceability information modelling". The workshop meeting minutes and results from literature study are enclosed in Appendix C. This report will be the common conclusion in the projects 1 and 2, and is a cooperation between SINTEF Fisheries and Aquaculture, NTNU, Nortura, and Norges Sildesalgslag (NSS). Innovation Norway has been an important financial partner for the literature study and the workshop

4 4 2 Traceability information Information that is fundamental and necessary to identify and physically trace the products is defined in the TraceFish standards (CWA ) as Shall information. All other information in this standard is categorised as Should or May information and may be regarded as product properties rather than traceability information. The Shall category is constituted of information elements already used and/or exchanged between food business operators. Examples of Shall information in TraceFish are: Food business ID (Identification of supplier, producer and customer) Logistic Unit ID (Identification of received and sold product e.g. pallets, containers) Trade Unit ID (Identification of received and sold product e.g. boxes, bins, cases) Date and time (dispatch and reception of logistic or trade unit) Related created trade unit ID s (Identification of received and sold product that are related to the traceable unit in focus) Type of Unit (Description of created unit) Net Weight (Net weight of created unit) Fundamental and necessary information for tracing and tracking according to the TraceFish standard is in this document defined and denoted as traceability information. 3 Traceability information exchange versus existing B2B information exchange This chapter will analyse and give recommendations on how traceability information should be related to existing B2B information exchange in the supply chain. Relevant descriptions on supply chain information exchange for B2B and traceability information will be presented first. Then possible routes for traceability information will be presented in Unified Modelling Language (UML) use case models Supply chain information (B2B) exchange Efficient supply chain operations depend on electronic information exchange between trading partners. CSCMP (Council of Supply Chain Management Professionals) defines a number of standard processes as shown in Figure

5 5 Figure 3-1 Standard business processes and information flow in a supply chain. Adapted from Senneset, Forås et al Standardized processes are the basis for developing standards for efficient information exchange. The interface between the processes Source and Deliver between two companies in the supply chain consists of a set of sub-processes with corresponding messages between the companies (CSCMP, 2004). Examples of sub processes are: Supplier management Purchasing Order management Warehousing/Fulfilment Transport In-bound material management Examples of messages are: Request for quote (RFQ) Purchase order (PO) Order confirmation Advanced shipping notice (ASN) Proof of delivery/in-transit Visibility Invoice Payment 3.2 Traceability information exchange in supply chains To enable traceability of food products through the supply chain, traceability information must be transmitted and recorded by all involved companies as shown in Figure 3-2. The principles of data capture of chain traceability and internal traceability information are shown in Figure 3-2. The figure shows the same CSCMP standard processes as defined in cchapter 3.1. As a basis for chain traceability, the identities for traceable units must be recorded at reception and shipping (see top vertical arrows in Figure 3-2). Internally in each link in the chain, the same type of recording should be made at merging and splitting of materials/items.

6 6 Figure 3-2 Data capture points of traceability information. From Senneset, Forås et al Use of traceability information This section describes the most relevant processes to create exchange, and use traceability information in a supply chain. The different actors and processes are presented in UML use cases. The Norwegian pelagic fish chain is used as an example. The following use cases for transfer of traceability information are specified and described: Request traceability information related to the Source process Push traceability information (report) as part of Delivery, e.g., part of ASN/Despatch advice or Packing list Request traceability information independently of business messages (e.g. recalls) Submit traceability information to a commodity market Case 1. Preliminary verification of traceability information as part of request quote. A Russian importer of fish (Buyer) considers multiple batches of herring from a number of exporters (Suppliers) as potential purchase objects. The importer sends request quotes for price, freight method, quality, estimated time of arrival, and additional information about the traceability history of each batch. The Norwegian herring exporters respond by sending response quotes including traceability information.

7 7 Figure 3-3 Use case 1 describing preliminary verification of traceability information Case 2. Push information (report) as part of Delivery, e.g. part of ASN or Packing list. When an exporter (Supplier) for herring has sold a batch of fish, they may send an advanced shipping notice (ASN) and/or packing list to the buyer or consignee. This shipping notice may also include traceability information for all relevant traceable units. In cases where the fish is shipped directly from the fish processor (Consignor) to a buyer or consignee, the consignor may also send the same type of information. In some cases supplier and consignor can be the same food business operator. The same applies to buyer and consignee. Supplier Buyer Send advanced shipping notice with traceability information Consignor Consignee Figure 3-4 Use case 2 describes reporting traceability information as part of delivery Case 3. Request traceability information. A prerequisite to be able to track and trace trough the chain is the ability to send and request corresponding reports of traceability information between all the actors in a supply chain (Figure 3-3). A possible case is described below.

8 8 Buyer (supplier primary connection) Request traceability information Supplier Subsequent chain actors Report traceability information Government body Consumer Figure 3-3 Case 3: Request traceability information To document the legality of a catch of fish, the governmental body Fiskeridirektoratet (F.Dir.) requests traceability information and information about quota etc. from the fishermen and the fish processors. After receiving sufficient information, a proof of legality, e.g., an electronic certificate may be issued by F.Dir. and sent to the chain actors responsible for landing (subsequent chain actor in Figure 3-3). This certificate is then sent together with the traceability information to the parties that require information about legality (Supplier and Consumer in Figure 3-3). The retailer (Supplier) has in advance requested information from the upstream supply chain (Buyer and subsequent actors) about traceability information (case 2). The certificate ca then be accessed through the Enterprise Resource Planning (ERP) system or traceability system. If a consumer is asking questions about the origin and legality of a certain type of fish the certificate may then be displayed if authorised. In one of the most serious food scares in Norway, the E.-coli case in 2006, extensive information about process and products in addition to traceability information were required by the governmental bodies as reported by Nortura representatives. Some of this information was also exchanged electronically. This case should be regarded as an important example of the Governmental body role and the use of information in a food scare case where a withdrawal was necessary. Case 4. Submit to electronic commodity market/commodity exchange. A fourth use case is defined when traceability information is submitted and flows through electronic commodity markets. An example of this is the situation where fishing boats (Suppliers) transfer their catch information into Commodity market represented by a web-based auction system. Traceability information may

9 9 be sent and presented at the same commodity marked and accessed by buyers and Governmental bodies. Figure 3-4 Case 4: Submit to electronic commodity market/commodity exchange 3.4 Traceability information analysis There may be situations where traceability information is required as the single type of information. However, in all the use cases business related (B2B) and traceability information are coexisting and that is supposed to be exchanged between the same partners at the same time. This statement is supported by the correspondence between data capture points and exchange partners in Figure 3-1 and Figure 3-2. In the Norwegian pelagic project (ref. project 1 in Chapter 1), electronic interoperability of B2B information did not exist prior to the project start. The project partners required that if an electronic traceability information exchange standard was to be established, it should also include quality and other B2B information. This was expected to increase the utilization and return of investment of such an implementation. The TraceFish standard includes a lot of additional quality, process and product information. This was based on the fact that the industry regarded traceability information and other B2B information as inseparable in the daily B2B communication. A research project carried out by a Norwegian meat producer (GILDE) in , focused on utilization of combined quality and traceability data. The data was intended to be used as a basis for production optimizing model in the GILDE enterprise. A prerequisite in this project was that quality and traceability information should be interlinked and exchanged between different systems using common protocols. (Bechini, Cimino et al. 2005) confirms the statements above through their conclusion: the traceability (and quality) information must always be transmitted in a secure and reliable way. Such a kind of communication, especially when different enterprises are involved, can be regarded as an e-business transaction. For this reason, the adoption of e-business protocols becomes both appropriate (because of the very nature of transactions) and convenient (as the interaction takes advantage of an established technological support).

10 10 Based on these facts the following observation has been made: Traceability information and B2B information are strongly interrelated by being created and consumed within the same business processes. This observation suggests that: Traceability information should not be managed independently from other B2B information. Traceability information and B2B information should be exchanged through the same mechanisms. 4 Relevant electronic information exchange standards This chapter describe relevant electronic information exchange standards for relevant business operators. An analysis of these standards regarding their applicability to include traceability information will then be made. 4.1 UBL The Universal Business Language (UBL) 4 is a standard intended to solve the disadvantages of having several different data formats across different business context. It addresses this problem by defining a generic XML interchange format for business documents that can be extended to meet the requirements of specific industries. Specifically, UBL provides: A library of XML schemas for reusable data components. A set of 31 XML schemas for common business documents UBL is maintained by a Technical Committee (TC) at OASIS 5, a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces standards for web services, security, e-business, standardization efforts in the public sector, and for application-specific markets. The governance and operating procedures are transparent. The members set the agenda themselves using lightweight processes designed to promote consensus, and completed work is ratified by open ballot. They boast a member basis of more than 5,000 participants representing more than 600 organizations and individual members in 100 countries. The UBL is designed to accommodate the business processes from the customer asking for prices and information, through the ordering process to the delivery and payment. In specific there are 7 main business processes defined: Sourcing Ordering Fulfilment Initiate Transport Services Report Status of Goods

11 11 Billing Payment Also, in UBL a lot of thought has been performed into being able to identify the document, the items being sent, and all the involved parties. An item being traded can be identified with the following ID s: BuyersItemIdentification SellersItemIdentification ManufacturersItemIdentification StandardItemIdentification CatalogueItemIdentification AdditionalItemIdentification The ID s in the UBL are not restricted to any schema. For each ID it is possible to specify attributes that specify precisely what numbering schemes are being used. 4.2 The Instrumentation, Systems, and Automation Society (ISA) ISA ( is a leading, global, non-profit organization that is setting the standard for automation. As one of the products, ISA develops automation standards through the American National Standards Institute (ANSI). Two of these ISA/ANSI standards have been evaluated as relevant for electronic traceability information exchange; ISA 88 and ISA 95. ISA88 ISA 88 provides a consistent set of standards and terminology for batch control. The standard seeks to address the following problems: lack of a universal model for batch control, difficulty in communicating user requirements, integration among batch automation suppliers, and difficulty in batch control configuration. The standard defines a process model, a physical model, and a procedural control model. Based on the data models and attributes defined in ANSI/ISA Batch Control standard Part 2, a XML schema is developed. This XML schema is referred to as the Batch Markup Language (BatchML) and is organised by the World Batch Forum ( The Batch ML schemas are used to exchange information about recipes, equipment, and batch lists. ISA95 ISA95 provides a standard terminology and a consistent set of concepts and models for integrating control systems with enterprise systems that will improve communications between different parties. The Business To Manufacturing Markup Language (B2MML) is an XML-implementation of the ANSI/ISA 95 family of standards. B2MML defines the information that is used commonly by B2MML personnel, equipment, materials, maintenance, capabilities, product definition, production schedule, and production performance schemas.

12 12 Both BatchML and B2MML include elements for identification of batch, equipment, persons etc. These elements may be used to establish traceability. The element ID s are defined to only identify objects within related exchanged information sets. The element IDs are not intended to act as global object IDs or database index attributes. The base types for most elements in B2MML are derived from core component types that are compatible with the UN/CEFACT core component types. The UN/CEFACT core components are defined in a Core Components Technical Specification (CCTS) developed by the ebxml project, now organized by UN/CEFACT and ISO TC TraceCore XML TraceCore extensible Markup Language (TCX) is a standard way of exchanging traceability information electronically in the food industry, related to both format and data. The TCX is developed by the TRACE Project "Traceability Systems Group" (TSG) ( The TCX makes it possible to exchange information common for all food products, i.e., the identifying number, the origin, how and when it was processed, transported and received, the joining and splitting of units, etc. It is based on a document called Recommendations for Good Traceability Practice in the Food Industry (GTP). This is a practical guideline for food businesses preparing themselves for implementation of traceability oriented practice. TCX is a schema that is focusing on chain traceability. The version called Release Candidate 2 (RC1) has been made available since November Traceability of the swine value chain (P2P) The EU project Traceability of the swine value chain: SME s independence from famous trademarks, developed an XML protocol to support the data collection from the traceability systems in companies belonging to the swine sector. This XML protocol was named The TraceXML and is a communication protocol developed in order to share the information strictly related to the traceability purposes. The Trace XML protocol defines both a communication protocol and a data representation based on existing standards; XML, SOAP, and WSDL). Regarding the data representation, the P2P consortium decided to adopt the following terms in the definition of the Trace XML protocol: Company: a company belonging to the agri-food value chain Item: represents the products both managed internally and delivered along the value chain Batch: represents the batches of products both managed internally and delivered along the value chain The software architecture conceived in the P2P project is distributed and the TraceXML protocol does not have any company data synchronisation specification. Traceability data of a company is stored only in one server, thus replication error or out-of-date information is avoided. In this scenario, data synchronization is relevant and important only when the company is going to publish its traceability information picking the information from its own legacy system. In this case, data must be correctly read from the archives and uploaded to the server that supports Trace XML. User groups as consumers, public officers and health care, veterinaries etc., may use the Trace XML, but they will not have access to the same amount of information.

13 13 TraceXML is only designed for exchange of traceability information as defined in Chapter Analysis of these standards regarding combining regular B2B information with traceability information UBL UBL was designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO (ebxml) to provide a complete, standards-based infrastructure that could extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees. As such, it is extremely well suited for exchanging B2B information. Also a lot of thought has been given to identification within UBL, both of the documents, the items being sent, and the parties involved. The ID s in the UBL are not restricted to any schema, thus it should be possible with minor effort, to implement the necessary identification for achieving good traceability information/data. ISA Both BatchML and B2MML provide standardised terminology, methodology; and XML schemas for exchange of information. These XML standards include some traceability information such as ID s on batches, sites, equipment and personnel. This indicates that these standards may also be used for exchange of traceability information. The scope of the standards is however focusing on information exchange between equipment and applications internally in a company and not in a supply chain. The BatchML and B2MML are therefore regarded as more applicable for internal traceability rather than chain traceability. TraceCoreXML (TCX) TCX is a standard way of exchanging traceability information electronically in the food industry. As such, it is an excellent way of transmitting traceability information. However, other B2B information is only supported through flat generic property fields. Trace XML TraceXML is a relevant protocol for exchange of traceability information, but the design criteria and focus is somehow dissimilar to the B2B traceability information approach in this report. TraceXML is designed for sharing information strictly related to traceability. Assuming that information strictly related to traceability is equivalent with our definition of traceability information in Chapter 2, this design is not adequate to B2B information flow. The conclusion is that TraceXML is applicable to carry traceability information and well designed for users such as consumers and public officers. TraceXML has to be sent as independent messages parallel to B2B information exchange and does not comply with our recommendations in Chapter 3.4: B2B- and traceability-information should not be separated. 5 Comparing TCX and UBL The conclusions in Chapter 4.5 point out that TraceCore XML and UBL are the most applicable normative standards for exchange of traceability and B2B information. This chapter will present a comparative analysis between these two solutions where the ability to carry all fundamental traceability information is examined. There will also be made a comparative analysis to define the possibilities in UBL to express all necessary B2B information in the case of

14 14 exchanging information between the Norwegian sales organisation for pelagic fisheries (NSS) and a processing plant in the Norwegian pelagic fisheries. 5.1 UBL vs. TCX with regards to Traceability Since TCX is a proposed standard specifically made for exchange of traceability information, we will compare UBL to this standard to assess UBL s level of completeness with respect to traceability. There is currently no document in UBL that is devoted exclusively to traceability like the TraceDocument in TCX. However, a lot of the necessary information for traceability can be found in the documents already defined in UBL. Of the documents already defined in UBL the DespatchAdvise is the document most relevant to traceability. This document is transmitted to the buyer from a seller when an order is shipped and provides detailed information about the order. If we make a detailed comparison between the TraceDocument in TCX and DespatchAdvice in UBL, we see that all the mandatory fields in TraceDocument is covered by DespatchAdvice. However, where TraceDocument demands a unique ID on the TraceDocument-, despatch- and delivery party, DespatchAdvice only demands that the despatch and delivery party are specified, not necessarily by a unique ID, and the signature option which is the equivalent of the TraceDocument party is also optional. This can be remedied by making user defined customizations of UBL where these demand are enforced. To ensure traceability between companies this customization needs to be universally accepted. DespatchAdvise has a field called CustomizationID where such a customization may be specified. Figure 5.1 provides a comparison between the mandatory fields of TraceDocument and how they can be mapped to DespatchAdvise. TraceDocument DespatchAdvise TracedocumentID ID TracedocumentParty ID Signature SignatorParty EndPointID DespatchParty ID DespatchSupplierParty Party EndPointID DeliveryParty ID DeliveryCustomerParty Party EndPointID TraceUnit ID DespatchLine ID Legend (Mandatory field) (Optional field) 5.1: TraceDocument vs. DespatchAdvise Regarding the non-mandatory field we find that DespatchAdvise covers almost all of the information in TraceDocument. One of the exceptions is the Property field, a field in TraceDocument that can be used to specify generic information at various levels. DespatchAdvice has an equivalent AdditionalProperties at the Item level but not at the overall document level. TraceabilityRelation in TraceDocument is not available at the overall level in DespatchAdvise, but can be specified at the item level in DespatchLine. However, there is only support for OutputUnitID, so an extension is needed for InputUnitID, for example an InputProductTraceID as a [0..n] of BBIE ProductTraceIDType. Also, by extending the ItemInstance tag by

15 15 InputProductTraceID, TraceabilityRelation will be covered for all UBL documents since ItemInstance is a part of Item which is included in every UBL document. See Appendix A for an example of how this can be implemented. There is no immediate support for AggregationRelation from TraceDocument in DespatchAdvise. SubUnitID s may be specified in the DespatchLine, but there is no obvious placement for the MasterUnitID. It could be specified in the AdditionalInformation field for each DespatchLine. This once again requires the industry to agree on a defined customization of UBL. 5.2 UBL vs. TCX with regards to B2B We have undertaken a preliminary analysis of the gap between necessary data structures used in the Norwegian wild catch industries and UBL. The analysis shows that the modifications necessary is limited to an object in the <item> tag in the UBL-CommonAggregateComponents-2.0.xsd The UBL vessel object is too limited in a fisheries context. There is a need to submit exact information about the vessel along the traceability chain. A fishing vessel is characterized by several attributes: type of vessel, fishing gear, equipment, radio call signal etc. As a preliminary suggestion we foresee the structures suggested in Appendix B integrated into UBL basic/aggregated components. Further investigation has to take place concerning the use of generic product description types <property> in TCX and <AdditionalItemProperty> in UBL. If this construct is sufficient to describe any food product, UBL documents containing the <item> tag will be usable as trace documentation. 6 Conclusion and future work It is our conclusion that UBL includes/overlaps the TraceCore XML almost completely. TCX has the traceability relation as an extended possibility to express traceability, UBL needs a small extension to allow the same. All other business transaction information is better supported in UBL compared to the TraceCore XML s flat property structure. The methodology and tools for establishing code lists also gives UBL advantage compared to the TraceCore XML data dictionary. As we see it, there are three options here presented in prioritized order (Option 1 is the one we recommend): 1. Use available UBL documents and form a subcommittee to expand the current documents or establish a recognized traceability customization of the documents. 2. Establish a technical committee or subcommittee in OASIS and work for the acceptance of a specific traceability document in UBL for example the TraceDocument from TCX. 3. Continue working on TCX within the Trace project, adapting to the UBL standards.

16 16 7 Appendices Appendix A: InputProductTraceID Appendix B: Vessel information Appendix C: Minutes of meeting; European workshop for food traceability information modelling Appendix D: Workshop invitation Appendix E: OASIS and TraceCore XML Appendix F: Data Modelling and ebxml for Supply Chain Traceability Appendix G: TraceCore XML Release Candidate 2 Appendix H: TraceCore XML used in a fish industry pilot project Appendix I: Pelagic sample file based on TraceCore XML RC2 Reference Bechini, A., M. G. C. A. Cimino, et al. (2005). A General Framework for Food Traceability. Proceedings of the 2005 symposium on applications and the internet workshops (SAINT-W'05). Bello, L. L., O. Mirabella, et al. (2004). Modelling and Evaluating traceability systems in food manufacturing chains. The 13th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE*04). CWA14660 (2003). Traceability of fishery products. Specification of the information to be recorded in captured fish distribution, Pronorm AS. Folinas, D., I. Manikas, et al. (2006). "Traceability data management for food chains." British Food Journal 108(8): FSA (2002). Traceability in the Food Chain A preliminary study Food Standard Agency. Garuti, M. (2005). TRACEABILITY OF THE SWINE VALUE CHAIN: SMES INDEPENDENCE FROM FAMOUS TRADEMARKS, Sixt Framework Programe COLL-CT Johnsson, C. (2006). ISA 95 For beginners. D. Brandl, The 282 Group. Senneset, G., E. Forås, et al. (2007). " Challenges regarding implementation of electronic chain traceability." British Food Journal 109(10): TRACE (2006). Tracing the origin of food.

17 17 Tracefood.org (2007). TraceCore XML, TraceFood. Ubieta, F. (2006). European ICT Strategic Research Agenda for Agri-food & Rural development A vision for AMI@NEtfood project report. D. I. u. t. S. P. AMI@Netfood is a Project funded by the European Commission, Integrating and Strengthening the European Research Area / Thematic Priority IST. Toledo, Innpole.