MASARYK UNIVERSITY FACULTY OF INFORMATICS }w¤§¨!"#$%&123456789@ACDEFGHIPQRS`ye| System for IUU fishing control DIPLOMA THESIS Zdenˇek Zikán Brno, spring 2009 Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: Ing. Petr Adámek ii Acknowledgement I would like to thank Hvard Bjstad and Rolf P. Hancke for introducing me to the topic, and providing me with useful information when needed, my advisor Petr Adámek for helping me to push the work in the right direction, ystein Gran Larsen for his view and advices of a traceability expert, Ivo Papoušek and Ondˇrej Kuzník for grammatical corrections. And last but not least to my family and friends for their support and patience and VO himself for his mercy. iii Abstract Fishing is restricted by various laws and regulations in both national and international waters at many places of the world. It can be assumed that this practice will continue and authorities will demand more control over fishing. This thesis relates to the area of traceability and focuses specifically on domain of traceability of fish products with respect to identifying fish and fish products which are introduced in a way infringing law and regulations. Furthermore it exploits possibilities of software for fighting illegal fishing. It suggests a software system based on TraceTracker's GTNet software which can help to recognize IUU fishing, designs such software and as a part of this work, prototype of such software is implemented. iv Keywords illegal, unregulated, unreported, IUU, fish, fishing, food, traceability, Java, UML, Java Server Faces, GTNet v Contents 1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Introduction to the problem domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 What is IUU fishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 What is traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Why do companies need traceability solutions . . . . . . . . . . . . . . . . . . 4 3 Traceability in details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 GS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Roles in the traceability process . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1 Information process flow role . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Physical process flow roles . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Traceable item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Minimum Data Requirements for Traceability . . . . . . . . . . . . . . . . . . . 9 4 GTNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 GTNet Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 GTNet Access Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 GTNet Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4 GTNet Capture Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5 GTNet Query Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 GTNet Conceptual Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1 Trade unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.2 Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.3 Production batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.4 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.5 Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.6 Operations on specific entities . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.7 Example of data model . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7 Core solution technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7.1 XML Schemas (XSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.7.2 Traceability Resource Definitions (TRD) . . . . . . . . . . . . . . . . . . 16 4.7.3 TraceTracker Data XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.8 Core platform technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.9 Frontend applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5 IUU Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1 Regional fisheries organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Traceability and IUU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6 Traceability Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 TraceFood and TraceCore XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 EPCglobal and EPCIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7 Actors in fishing and fish processing industry and use cases . . . . . . . . . . . . 20 7.1 Parties involved in the fish market . . . . . . . . . . . . . . . . . . . . . . . . . 20 vi 7.2 Places where IUU can be introduced . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.1 Fish farming companies . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2.2 Vessel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.3 Between Vessel and Processing . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.4 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8 Business requirements for IUU monitoring system . . . . . . . . . . . . . . . . . . 25 8.1 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2 Technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3 Non-technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.4 External prerequisities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1 Register Catch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2 Register Received Fish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.3 Register Stock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4 Register Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.5 Register Sale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.6 Get IUU certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.7 Set quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.8 Retrieve quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.9 Display products chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.10 Create actor mass balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.11 Check catch validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.12 Perform mass balance update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.13 Check actor mass balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.14 System extension for controlling purposes . . . . . . . . . . . . . . . . . . . . . 31 10 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.2 Actors' internal traceability systems and GANs . . . . . . . . . . . . . . . . . . 35 10.2.1 IUU Quotas Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2.2 IUU Certificates Database . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2.3 IUU Certificates Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.2.4 IUU Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2.5 IUU Quotas Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.3 Capturing notes in the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.4 Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.4.1 Generic quotas model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.4.1.1 Master data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.4.1.2 Transactional data . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.5 Certification system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 10.6 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 10.6.1 Design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 vii 10.6.2 Frameworks and Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.6.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.6.3.1 Java Server Faces . . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.6.3.2 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 45 10.6.3.3 JBoss Seam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 10.6.3.4 Echo3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.6.3.5 Wicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.6.3.6 RichFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10.6.4 User interface design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.6.4.1 IUU Certificates Manager . . . . . . . . . . . . . . . . . . . . . 47 10.6.4.2 IUU Quotas Manager . . . . . . . . . . . . . . . . . . . . . . . 47 10.6.4.3 IUU Inspector . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 11.1 Traceability Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 11.2 QCI ­ Quota Capture Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 11.3 QQI ­ Quota Query Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 11.4 CertQI ­ Certificates Query Interface . . . . . . . . . . . . . . . . . . . . . . . . 56 12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 A Illustration images and schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 B Data needed for fish traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.1 Captured fish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.1.1 Vessel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.1.2 Auction/collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.1.3 Processing/wholesale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 B.1.4 Retail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 B.2 Farmed fish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B.3 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 C QCI definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.1 QCI XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.2 QCI status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 D QQI definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 D.1 QQI XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 D.2 QQI status codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 E CertQI definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 E.1 CertQI XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 viii Chapter 1 Motivation No fish species population is unlimited and their excessive fishing may cause reduction of the population to a level when it is hardly possible for them to breed, which may cause an extinction. For this reason, fishing in both national and international waters at lot of places in the world is restricted by various laws and regulations. These regulations specify which species can be hunted, which means can be used so that the environment is not severely damaged, when various species can be hunted, so that it fits with their breeding cycles and so on. It can be assumed that this practice of regulations will not only continue but authorities will demand more control over fishing. It is already happening now (see Regulation (EC) No 178/2002 [18], Article 18). TraceTracker Innovation ASA is a software company which provides set of software for global traceability of products, i.e. monitoring of what is happening with the goods in the supply chain. The software is based around their main product ­ GTNet ­ which is a distributed network for keeping the traceability data. Upon GTNet, other ­ both client side and server ­ software is built. The idea behind this thesis is to exploit the area of IUU (Illegal, Unregulated, Unreported) fishing, the way how the regulations are made, and the possibilities of making use of this existing infrastructure in traceability software for monitoring fishing industry in a way which helps both regulation authorities and fish trade partners to distinguish legal fish products from those that violate regulations. 1 Chapter 2 Introduction to the problem domain 2.1 What is IUU fishing IUU is generally used in the context of fishing as an abbreviation for Illegal, Unreported, Unregulated. According to definition on [12] i.e. recognized by Norwegian Ministry of Fisheries and Coastal Affairs and several other fishing- and seafood-related authorities 1, Illegal, Unreported, Unregulated refers to following. Illegal fishing refers to fishing activities * conducted by national or foreign vessels in waters under the jurisdiction of a State, without the permission of that State, or in contravention of its laws and regulations; * conducted by vessels flying the flag of States that are parties to a relevant regional fisheries management organization but operate in contravention of the conservation and management measures adopted by that organization and by which the States are bound, or relevant provisions of the applicable international law; or in violation of national laws or international obligations, including those undertaken by cooperating States to a relevant regional fisheries management organization. Unreported fishing refers to fishing activities * which have not been reported, or have been misreported, to the relevant national authority, in contravention of national laws and regulations; * or undertaken in the area of competence of a relevant regional fisheries management organization which have not been reported or have been misreported, in contravention of the reporting procedures of that organization. Unregulated fishing refers to fishing activities * in the area of application of a relevant regional fisheries management organization that are conducted by vessels without nationality, or by those flying the flag of a State not party to that organization, or by a fishing entity, in a manner that is not consistent with or contravenes the conservation and management measures of that organization; 1. Institute of Marine Research, the Directorate of Fisheries, the National Institute of Nutrition and Seafood Research, the National Veterinary Institute and the Norwegian Food Safety Authority 2 2.2. WHAT IS TRACEABILITY * or, in areas or for fish stocks in relation to which there are no applicable conservation or management measures and where such fishing activities are conducted in a manner inconsistent with State responsibilities for the conservation of living marine resources under international law. 2.2 What is traceability Let's try to define the main topic which will be discussed and used in the rest of the thesis ­ traceability. * ISO 8402:1994 gives us quite general definition: "Traceability is the ability for the retrieval of the history and use or location of an article or an activity through a registered identification." [16] * WWF puts traceability into food products context as "Ability to track the movement of a food product through specific stages of production, processing and distribution along the product's supply-chain". ([33], page 8) * The European Union specifies it as "the ability to trace and follow a food, feed, food-producing animal or substance intended to be, or expected to be incorporated into a food or feed, through all stages of production and distribution" in Regulation (EC) No 178/2002 [18], Article 3.15, which is the one which I will be relating to. When discussing traceability, terms tracing and tracking are often distinguished. Tracing is the retrieval of information to reconstruct the history of a shipment, package, etc. From the users' perspective, it may be defined as the following-up of trade items upstream. Tracking is the retrieval of the actual status of a shipment, a package, etc. It is the capability to follow the path of a specified unit and/or batch of a trade item downstream through the supply chain as it moves between trading partners. ([13], pages 9-10) Having traceability of production means having the ability to answer 5 key questions about inputs, production, and outputs [1]: * Where did it come from? * How did it get here? * What did we do with it? * Where did it go? * How did it get there? Example of supply chain can be found in Appendix A. 3 2.3. WHY DO COMPANIES NEED TRACEABILITY SOLUTIONS 2.3 Why do companies need traceability solutions Capturing traceability data, providing them (some or all of them) to their business partners, and having the ability to view the whole supply chain can help the company in several ways. * Enables visibility of inventory across the supply chain and synchronization of consumption and procurement, which may have positive effect on company's cash- flow. * Facilitates validation of the presence or absence of attributes important to consumers and customers, such as product certificates or origin, information about farming methods, whether the food is kosher, fair trade, sugar-free, cosmetics nonallergenic, or not tested on animals. * Allows manufacturers to identify and locate defective products and remove them from commerce. Moreover, with accurate and quick data access, manufacturer can identify those and only those products which are defective, thus minimizing loss when there is a need for product recall. This helps to protect brand and company value. * Is demanded by some countries as a safeguard against bioterrorism. [26], [10] 2 * Fights product counterfeiting, because if provides product authentication. * Assures compliance with legal and commercial requirements, rules and restrictions. Summary of European Union attitude to traceability as a protective tool can be found in EU Factsheet on Food Traceability [11]. 2. although [10] does not explicitly use the word terrorism 4 Chapter 3 Traceability in details To manage traceability across the supply chain, we need to associate information flow with the physical flow of traceable items, either step-by-step, as depicted on the Figure 3.1, or via some third party that centralizes traceability data storage and retrieval. Figure 3.1: Traceability across the supply chain [14] Internal traceability is a process that takes place when a traceability partner some traceable items (goods), processes them somehow and outputs some instances of traceable items (which may or may not be the same as in the beginning). Internal process is a process or set of sub-processes without significant involvment of other trading partners. It may include movement, transformation (such as mixing or cooking), storage, or destruction (waste). The traceability partners must maintain their internal traceability information, and may or may not display it to their partners. See Figure 3.2. External traceability takes place on handing over the traceable item between traceability partners. Each partner must be able to trace traceable items going through him one step back to its direct source and track it one step down, to its direct recipient. Moreover, each item 5 3.1. GS1 Figure 3.2: Internal traceability [14] must carry unique identification during the whole chain until it is consumed or destroyed. The uniqueness is ensured by the brand owner. This all ensures that the traceability partners must not hold all the information about items, but they are able to communicate the whole chain. See Figure 3.3. 3.1 GS1 Industry standards exist in the area of traceability. The most widely used is set of GS1 standards. GS1 is non-profit worldwide organization formed by joining EAN International and UCC, which creates set of standards to "improve the efficiency and visibility of supply and demand chains globally and across multiple sectors" [15]. Their products include numbering schemes for trade items, shipments, locations, information register (GEPIR) and also GS1 Traceability, the set of recommendations for enabling products traceability. We will refer to some of their recommendations and standards in the next chapters. 6 3.2. ROLES IN THE TRACEABILITY PROCESS Figure 3.3: External traceability [14] 3.2 Roles in the traceability process In the traceability process we distinguish several roles which different participants can have. Here we use definition of roles from GS1 guidelines [14] (definitions are directly quoted) and provide example of such roles on more concrete examples. 3.2.1 Information process flow role TRADING PARTNERS: * Brand Owner ­ The party that is responsible for allocating GS1 System numbering and bar code symbols on a given trade item. The administrator of a GS1 Company Prefix. And/or the party that is the ultimate authority for the trade item. And/or the owner of the product specifications. And/or responsible for placing a traceable item into commerce. * Traceability Data Creator ­ The Traceability Partner that generates traceability in- formation. * Traceability Data Source ­ The Traceability Partner that provides the traceability information. 7 3.3. TRACEABLE ITEM * Traceability Data Recipient ­ The Traceability Partner authorized to view, use, and download traceability information. * Trace Request Initiator ­ The person who starts the trace request. 3.2.2 Physical process flow roles TRADING PARTNERS: * Traceable Item Creator ­ The Traceability Partner that generates a traceable item, or makes a distinct traceable item by transformation of one or more traceable items. * Traceable Item Source ­ The Traceability Partner that dispatches or provides a traceable item. * Traceable Item Recipient ­ The Traceability Partner that receive the traceable item. * Transporter ­ The Traceability Partner that receives, carries, and delivers one or more traceable items from one point to another without transforming the traceable item(s). Typically only has possession, custody, or control of a traceable item, but may have ownership. 3.3 Traceable item Traceable item is a generic term referring any entity which can be subject of traceability, whether its part of the production process or trade. GS1 recognizes [14] several types of traceable items. According to product packaging or logistical hierarchy, from the highest level to the lowest, GS1 divides them to: * Shipment ­ it may contain one or more logistic unit(s). Examples include truckload, vessel, 10 pallets of various items. * Logistic unit ­ it may contain other logistic unit(s) or one or more trade item(s) or it may directly be a trade item. Examples include pallet, container. * Trade item not crossing the point of sale ­ it is the item that is subject to trade, on contrary to logistic unit or shipment, that are used to simplify transport and referencing more trade items. It may be a trade item, batch/lot of trade items (trade item where only batches/lots are distinguishable, not items within single batch/lot), serialized trade item (trade item where every single item is distinguishable). Examples include carton of eggs, bag of rice etc. * Trade item crossing the point of sale ­ the same, but it is sold to the end consumer. 8 3.4. MINIMUM DATA REQUIREMENTS FOR TRACEABILITY All traceable items must carry a global, unique identification directly on the traceable item, or if not possible, at least on the asset containing it, or on an accompanying document. Image Figure 3.4 shows the identification matrix of GS1 standards for identification and traceables for which they are used to. Figure 3.4: GS1 traceable item identification matrix [14] There are, however certain differences between GS1 division and that of GTNet ­ a distributed network for sharing and managing traceability data, which is more thoroughly described in Chapter 4, "GTNet". GTNet does not differentiate shipments and logistic units and handles trade items crossing/non-crossing point of sale in completely same way. Instead, every not-traded traceable that involves in internal company processes is called batch, every item that is traded is called trade item, for referencing collections of trade items, it uses clusters, instead shipments and logistic units. In fact, the concept of shipment is not used at all ­ if needed, it can be supplemented by clustering. More thorough description of GTNet model can be found in Section 4.6. 3.4 Minimum Data Requirements for Traceability To make global traceability process possible, there are several conditions which need to be satisfied. [2] * Each traceable unit must be uniquely identifiable when it is between traceability 9 3.4. MINIMUM DATA REQUIREMENTS FOR TRACEABILITY partners ­ i.e. between each shipment and reception. * Identities of traceable units must be recorded at reception and shipping. * Manage internal traceability, which means ­ record the unique identities of traceable units (typically input to processes), ­ assign unique identities to new traceable units (typically output from pro- cesses), ­ link a set of input (sourced) unit identities to one or more sets of output (delivered) identities. In other words, company must be able to identify traceable units inside of its internal process, know what is happening with them and link its inputs and outputs to the unique identification in the global chain. Managing internal traceability is, in fact, not absolutely necessary, when the company keeps track of its partner to whom it send of from whose it receives products, however, without it, the traceability brings less additional value for the company. More info on GS1 Traceability can be found in [14] ­ refer to pages 15-16 for broader view on which data need to be captured. 10 Chapter 4 GTNet GTNet1 is subscription-based service and distributed software upon which the service is operated, which enables companies to implement electronic traceability both internally and across their trading partners. On the global level, it allows view on the whole supply chain while each company providing only its own part of the traceability data with connection on the partners one step back and forward in the chain. Figure 4.1: GTNet architecture The whole network is separated into domains, in between which the GTNet Naming Service (GNS) operates. Each domain is represented by one central GTNet Hub, to which GTNet Access Nodes are connected. GTNet Access Nodes are usually run one per company or company part and they are the main points where traceability data are stored and serve for accessing those data. The "hub approach" makes it easy to provide data transparently to other businesses in the chain, independent of their internal systems, while shill having control over their data at all times. One can control in an unified way which data are exposed to respective stakeholders in different situations. The Hub only routes data between GTNet 1. stands for Global Traceability Network 11 4.1. GTNET HUB Access Nodes and the business critical data is always kept locally within reach and control of each individual company. See Figure 4.1. Figure 4.2: GTNet Access Node architecture [24] The GTNet is built solely on open standards and protocols, thereby enabling external stakeholders to get easy access to their data, with no need to use proprietary software to do this and enabling them to build their own software using GTNet. Protocols used include HTTP for browsing, documented XML format for data import and for traceability domains definitions, SOAP for querying through Web Services, or XSD for defining data formats. It also communicates with GEPIR 2 and uses GS1 standards to identify traceable items. See Figure 4.2. 4.1 GTNet Hub The GTNet Hub is a node in the network which coordinates communication between different GTNet Access Nodes and other GTNet Domains. Each domain has only one GTNet Hub. Moreover, it serves as cache for data from GANs. 2. Global Electronic Party Information Register ­ distributed database that contains basic information on many companies, run by GS1 12 4.2. GTNET ACCESS NODE 4.2 GTNet Access Node A GTNet Access Node (GAN) is an end point in the GTNet. A GAN is in fact a specification for interfaces and can be implemented by any vendor. Currently, the only used implementation is TraceTracker's Traceability Information Exchange (TIX). A GTNet Access Node represents one organization in a traceability chain, or one business unit for large companies. GANs don't communicate directly, instead they use GTNet Hub ­ each GAN communicates with one Hub. A GTNet Access Node operates either as a data provider for other nodes or as a data collector for end users. 4.3 GTNet Name Service The GTNet Name Service (GNS) allows a GTNet Hub to find information about organizations and nodes in the GTNet. It can be thought of as about service somehow similar to DNS. 4.4 GTNet Capture Interface The GTNet Capture Interface (GCI) is an interface implemented by GAN to import data. GCI Protocol is built on top of HTTP (possibly with SSL encryption) and allows clients to import or rollback traceability data, import TRDs3, data about organizations, users and roles. It is also used by GTNet Access Nodes to export information about links into GTNet Hub ­ in that case, traceability data itself remain in GTNet Access Node and they are only referenced in the Hub. 4.5 GTNet Query Interface The GTNet Query Interface (GQI) is and interface for querying and retrieving data from the GTNet (via GAN). Currently this can be done through Web Services using SOAP, however, new connectors can be added to support different means. Using GQI one can query organizations, TRDs, traceability data, audit logs, users and roles. 4.6 GTNet Conceptual Data Model This chapter describes conceptual data model that GTNet uses for representing the chain. This model is further refined for specific domain using Traceability Resource Definitions described later in Section 4.7.2. 4.6.1 Trade unit Atomic piece of product traded. It is thus part of the external traceability process. 3. Traceability Resource Definition ­ file that defines specific traceability domain, see Section 4.7.2 13 4.6. GTNET CONCEPTUAL DATA MODEL 4.6.2 Batch Basic traceable entity in internal process. It may represent some basic amount of specific product, byproduct, intermediate product etc. 4.6.3 Production batch The same as batch with the exception that it is also visible from "outside", by the other trade partners. Reasoning behind differentiating between this and normal batch is that some batches may be associated with recalls and withdrawals, so we want the information about them to be accessible to other partners. 4.6.4 Cluster Cluster is a special class of trade unit which serves to describe collection of traceable items, for example pallets with multiple pieces of trade units. (E.g. company is trading jars of jam, but for practical reasons, it's better to refer them not one by one, but refer to palette of jams). 4.6.5 Station Station is a special place for recording (environmental) parameters and associating them with traceable entities that pass through. It may be for instance a place where raw fish is stored and temperature sensors monitor send data into GTNet to keep track of temperature during the whole storage. 4.6.6 Operations on specific entities To describe production (i.e. internal traceability), GTNet uses transformations. All the traceables may undergo following transformations during the process: * Split ­ split input into multiple, smaller parts. E.g. created fish hydrolysate is poured into barrels, in which it is sent to the buyer. * Mix ­ combine multiple sources over time. E.g. fish guts, bones, cartilage, scales and unusable meat is put together for processing * Join ­ combine multiple sources into one entity. E.g. assembly computer parts. * Convert ­ carry out operation on an entity and give it a new name. E.g. boil some ingredients. * Station ­ expose entities to conditions over time. E.g. fish guts, bones, cartilage, scales, unusable meat and water is grounded up together. It is process that lasts for some time and it has various parameters, e.g. time, temperature. 14 4.7. CORE SOLUTION TECHNOLOGIES * Enter cluster ­ put single or multiple entities into cluster. E.g. put fish hydrolysate barrels onto palette used for transportation. * Leave cluster ­ get entities out of cluster. 4.6.7 Example of data model * Incoming shipment ­ the goods which are sent by another trading partner. In this step, receiver can tell which trading partner was the shipment received from. For the relation to be made in GTNet, both sending and receiving party must confirm the shipment, thus creating a link. * Received product ­ Products which were received but not yet processed. It may be different from incoming shipment because shipment may contain cluster (see further) of more products. * Production ­ product changes take place in here. * Finished product ­ after all the processing. * Outgoing shipment ­ some products (which may become cluster) sent to another trading partner. In this step, it is known which trading partner was the shipment sent to. For the relation to be made in GTNet, both sending and receiving party must confirm the shipment, thus creating a link. 4.7 Core solution technologies 4.7.1 XML Schemas (XSD) XSDs serve to describe structure of specific XML format. TraceTracker has defined the following data formats GTNet and related software uses: * Organizations. This file contains information about organizations in a traceability chain. * TRD. This file contains the traceability resource definitions for the current organi- zation. * Units. This file contains the different measurement units used in the TRD. Examples include temperature units like Celsius and Fahrenheit, and size measurements like centimeters and inches. The software comes with a default unit file that does not need to be changed. * Data. The actual traceability data. 15 4.8. CORE PLATFORM TECHNOLOGIES * Data Access Control. Data access control lists describing which security roles have access to certain types of data. 4.7.2 Traceability Resource Definitions (TRD) The traceability model GTNet uses is generic enough to be usable in any industry and suitable for capturing any traceability chain. Due to this fact, before using within a new industry (deploying at new customer), the system has to be configured so that data are connected with semantic information. TRD ­ Traceability Resource Definition is the tool for it. It is XML file which defines the set of names, parameters, the traceable entities and concepts in the traceability system and must be installed in the system before it can be used or administered further. Any set of data from then on must be linked to some TRD. 4.7.3 TraceTracker Data XML The format for capturing traceability data itself. These XML files must follow structure defined by referenced TRD and thus varies by industry. It specifies Batches, Production Batches, Trade Units, Clusters, Stations, their creation, destruction, mixing, joing etc. Operations are listed and described in section Data model. 4.8 Core platform technologies Currently the only officially supported operating system is Linux, though it is possible to run it on other operating systems, including Microsoft Windows or Unix systems. To make portability and possible support for other operating systems easier, all the software is written using Java. Desktop frontend applications using Java SE 5.0, server-based applications use J2EE 1.4, requiring compliant J2EE application server. Currently supported is JBoss Application Server 4.0.3SP1 and later, support for WebSphere Application Server 6.1 is being dropped. As database backend, PostgreSQL is used. 4.9 Frontend applications There are several frontends for this network, such as * TT Navigator ­ web application serving as main GTNet user interface, for user management, uploading data and TRDs, querying and visual browsing data, * IANG ­ desktop Java Swing-based application for manually uploading data, * Data Uploader ­ application for automated XML data uploading, which checks for changes in specified directories and imports data which appear there. 16 Chapter 5 IUU Control In 1983, European Union has created Common Fisheries Policy, which was later reviewed in 2002 and 2008. "This policy deals with the biological, economic and social dimension of fishing. The Common Fisheries Policy shall provide for coherent measures concerning: * conservation, management and exploitation of living aquatic resources, * limitation of the environmental impact of fishing, * conditions of access to waters and resources, * structural policy and the management of the fleet capacity, * control and enforcement, * aquaculture, * common organisation of the markets, and * international relations." [6] "The 2002 reform of the CFP opened for a more long-term approach to fisheries management, involving the establishment of multi-annual recovery plans for stocks outside safe biological limits and of multi-annual management plans for other stocks. It aimed to progressively implement an eco-system-based approach to fisheries management." [5] It sets quotas for which member states are allowed to catch what amounts of each type of fish, as well as tries to encourage the fishing industry by various market interventions. Regulations include production, quality, grading, packaging and labeling is done. "Each country is given a quota based upon the total available and their traditional share of the catch (Total Allowable Catch, TAC). TACs are fixed annually by the council of ministers in December. They consider proposals drawn up by the European commission in consultation with its own scientific advisers (Scientific, Technical and Economic Committee of Fisheries STECF), the views of non EU fishing nations and those of the International Council for the Exploration of the Sea (ICES). Each member state is responsible for policing its own quotas. Different countries distribute the available stock using different systems." [27] "Each vessel is allocated an individual fishing quota for regulated species. Catches and landings must be recorded. Regulations are made about the kind of fishing gear which may 17 5.1. REGIONAL FISHERIES ORGANISATIONS be used. Areas may be closed from fishing to allow stocks to recover. There is a minimum size for fish which may be landed. This led to a practice of simply dumping dead fish which were too small to be landed legally, so a minimum mesh size was introduced, allowing small fish to escape and replenish stocks. Choice of mesh is complicated because mature fish of different species are naturally different sizes and different nets must be used." [27] "Enforcement involves managing quotas and implementing technical measures to preserve fish stocks. Inspectors may check fishing gear and inspect the register of fish caught. The type of fish caught will be checked and compared to quotas of total permitted catch for a vessel. Checks may be made in port or at sea, and using aerial photography." [27] 5.1 Regional fisheries organisations Regional Fisheries Organisations (RFOs) are created by international agreements. They provide a framework within which the representatives of governments agree on ways of managing the fish resources of the open seas, which are outside the jurisdiction of the individual states. The RFOs play a key role in combating illegal, unreported and unregulated fishing (IUU) and destructive fishing practices. The RFOs issue recommendations on management and conservation measures based on the best scientific advice available, which must be implemented by all their members. [8] 5.2 Traceability and IUU On October 17th 2007 the European Commission ­ Directorate-General for Maritime Affairs and Fisheries presented a new policy package and a proposal for a new Council regulation to combat IUU fishing. The new rules will apply to everyone, without exception. The Commission is introducing catch certificates which must "accompany the fisheries products throughout the market chain even if they pass through a number of territories before arriving in the EU market, including possible processing along the way." It is closing EU market to uncertified (i.e. untraceable) fishing products, blacklisting offending vessels and countries which allow them to operate, imposes penalties for breaking those rules and demands improved cooperation to manage flow/supervision of marine products. [19], [7] This creates the main motivation for providing electronic traceability solution for the fishing industry. 18 Chapter 6 Traceability Standards 6.1 TraceFood and TraceCore XML TraceFood is a framework which was created based on TRACE [23], SEAFOODplus [?] and TraceFish [25] ­ projects funded by EU ­ and intends to provide standards for fish traceability information exchange. Its main components are: * Identification through use of Global Trade Item Number (GTIN) * Generic Good Traceability Guidelines * Sector specific Good Traceability Guidelines * Documentation of transformations * TraceCore XML * Sector specific XML 6.2 EPCglobal and EPCIS EPCglobal is a joint venture of GS1 and GS1 US standardization organization with support of many vendors all over the world, with a goal of standardization of Electronic Product Code technology. Their EPCIS is EPCglobal standard designed to share EPC-related data across enterprises. The intent of this broad objective is to encompass the widest possible set of use cases and to not overly constrain the technical approaches for addressing them. The EPCIS consists of two interfaces and a data model. The main components of the data model include EPC, Event Time, Business Step, Disposition, Read Point, Business Location, and Business Transaction. It can further be extended for specifics of various industries. The interfaces are EPCIS Event Capture Interface which is used for communicating generated visibility data that to consuming applications ­ usually repository, and EPCIS Query Interface which serves to request business events from repositories and other sources of EPCIS data using a simple, parameter-driven query language. There are two types of queries ­ Poll Queries for a synchronous, on-demand response, and Subscription Queries for an asynchronous, scheduled response. More info in [28], [29], [9]. 19 Chapter 7 Actors in fishing and fish processing industry and use cases 7.1 Parties involved in the fish market The fish can be caught in wild or farmed on a fish farm. Hobby and leisure fishermen must be registered and pay the fee in most countries but the fishing itself is not reported neither in Norway nor in EU and thus we will not cover it at all. [13] Follows list of actors that participates in the whole fish market, including authorities that take place in the market control. As there are two very specific branches of fish production ­ farmed fish and fish caught in wild, we distinguish them where applicable. * Feeding (farmed fish) * Broodstock (farmed fish) * Hatchery (farmed fish) * Ongrowing (farmed fish) * Vessel (captured fish) ­ fishermen need to be registered in a fishermen register, and each of vessels is assigned some weght quota of fish distinguished by type and class. * Sorting/separating (captured fish) * Auction (captured fish) * Fish processing plant ­ they usually buy fish from the Fishermen sales associations. The fish can be landed from the vessel where it was caught or transported by other vessel or transporter. * Distribution/transport * Retailer or Horeca (Hotels/Restaurants/Catering) * Consumer * Authorities ­ Regional Fisheries Management Organisations 20 7.2. PLACES WHERE IUU CAN BE INTRODUCED ­ Producers' organisations (POs) ­ voluntary associations of fishermen set up to help stabilise markets. Their role is to protect fishermen from sudden changes in market demand. ­ European Union European Commission ­ specifically Directorate-General for Fisheries and Maritime Affairs and its commissioner. Sets and controls quotas for each state, imposes fines for not complying with quotas. European Food Safety Authority ­ provides independent scientific advice and communication on existing and emerging risks associated with the food chain. Its work covers all matters with a direct or indirect impact on food and feed safety, including animal health and welfare, plant protection and plant health and nutrition.. Community Fisheries Control Agency ­ coordinating the operational activities of Member States in the area of fisheries, and provides assistance to the Member States in their application of the CFP. Tax authorities ­ IUU fish will rarely be reported to these authorities and taxes most probably will not be paid. Customs ­ they are responsible for declaring goods going in and out of EU. They can stop any transport which is not able to show proper certificates of the cargo. ­ Norway-specific [3], [20]. The Directorate of Fisheries ­ controls Norwegian vessels in Norwegian and international waters, and foreign vessels in Norwegian waters in accordance with international law. Sets and monitors fish quota. Conducts inspections at land of fishing companies, anyone who, for business purposes, are in possession of fish intended for storage, transport or sale and of anyone in possession of documents concerning such fish. The Coast Guard ­ inspects Norwegian vessels in Norwegian and international waters, and foreign vessels in Norwegian waters in accordance with international law Sales Organizations ­ carry out registration and control of catches and landings (quantity and species). All catches to be sold must be sold through the sales organisations. All landings must be weighed and recorded on the sales notes, which provide the basis for the control of quotas. 7.2 Places where IUU can be introduced 7.2.1 Fish farming companies Scenario 1: The farming itself is not regulated in a way the captured fish market is. Thus 21 7.3. ACTORS there is no way how to fish illegally in a way the term IUU describes. However, fish products (potentially resulting from IUU fishing) can be used for feeding. Feeding, broodstock, hatchery, ongrowing can be places for this to happen. 7.2.2 Vessel Scenario 2: Fishermen can control which kind of fish they catch only to some extent1, so bycatches ­ situation when another kind of fish get stuck in the net, except the targeted species ­ often happen. That can be a problem when the quotas for that species have already been fulfilled and may lead fishermen to record the fish as different species. Scenario 3: Different catches of fish may be mixed in containers, so that the fish can be stored easier in less space. This may cause mixing of fish from several catches and stacking up the contract/landing notes to form one "super note" and then, it can be split into different containers and eventually mixed with other catches. This can create many-to-many relationship between caught fish and notes. Scenario 4: The quotas can be illegally transferred to a year before or after, it the catches are above or below the quota. This is called "paper fish" or "wall fish". 7.2.3 Between Vessel and Processing Scenario 5: The whole fish cannot be processed. There are parts of the fish which are unusable for consumption, so transforming 1 ton of fish to 1 ton of fillets is simply not possible. Yield factor (outgoing products mass divided by incoming mass) is an important measure which states how much of the end product can be made from some amount of raw fish. It is affected by properties such as "species, size, water content, fat content, filleting skills, season, additives used, fishing area, feed, processing methods, end product etc." [20] If fisherman catches more than his quota allows him to fish, he may black sell the over-the-quota fish to a processing plant or give it as an addition (processing company can pay more for such fish). The processing company then can mix IUU and non-IUU fish to fit into the official yield factor. In case the over-the-quota fish are sold black, the fisherman and processing plant avoid paying VAT/tax. 7.2.4 Processing Scenario 6: Some fish can be stored for several years (dried/stock fish). Therefore, it is necessary to keep track of which catch or batch the fish belong to even long time after the contract notes were issued. 7.3 Actors From the list above, the following actors can be identified. 1. using various fishing techniques or net types and mesh size 22 7.3. ACTORS * Fish farming company ­ the farming itself is not regulated in a way the captured fish market is. Thus there is no way how to fish illegally in a way the term IUU describes. However, fish products (potentially resulting from IUU fishing) can be used for feeding. Feeding, broodstock, hatchery, ongrowing can be places for this to happen. * Fish sender ­ The "Fish sender" is any actor that somehow transmits a mass of fish to another actor. He should provide receiver with the certificate of the mass of fish. * Fish receiver ­ any actor that receives a mass of fish from another actor. He should verify the legality of the fish. * Fish processor ­ any actor that somehow process or make any changes to the actual mass of fish. He should report what changes did he make. * Commission inspector ­ checks for over-the-quota fish, gathers statistical information to find out if regulations are enforced on national level. * National inspector ­ checks for over-the-quota fish, gathers statistical information, sets the quotas and restrictions. * Tax controller ­ he may want to know the differences between what was reported and what is the actual goods/money flow to find out possible tax frauds. * Customs ­ This role is an authority actor responsible for toll declarations of goods imported/exported from a national border. Customs can check the validity of the issued IUU certificates and stop and confiscate transports without any proper documentation and/or illegal goods. [20] In the following text, we will use UML actors for denoting roles in the system, not physical users. Diagram Figure 7.1 shows us the connection between real-world users and generic UML actors. 23 7.3. ACTORS Figure 7.1: Connection between real-world users and generic UML actors 24 Chapter 8 Business requirements for IUU monitoring system This part describes what are requirements for fulfilling our goal of making IUU fish distinguishable from legal catches and products. It will cover not only parts which should be implemented by me but also the general requirements needed for such system to work. 8.1 Non-functional requirements * Scalability: The system design itself should not restrict its scaling to large amount of users. This vague formulation means mainly that while inserting and updating data in the databases can take longer time if needed (minutes), querying databases should not be blocked by another operations because it will be used also interactively by end-users. * Open standards: The system interfaces should prefer using existing open standards (such as XML, SOAP, HTTP) to using proprietary or creating new protocols where not necessary. 8.2 Technical requirements * The system must be done in a way that allows it to be interconnected with other vendors' software without need for any major changes, so that the whole traceability solution is not vendor-dependent. * The system should be able to receive electronic messages from all actors in an agreed exchange format. * In [20], pages 16-18, various software architectures are described. From those, the centralised database architecture (Chapter 7.1.3) or combination of distributed and centralized database architecture (Chapter 7.1.4) would be good to achieve our goals. We decided for combined architecture to be used, because existing GTNet infrastructure can be used to make the implementation easier. The system will thus have distributed nature with data kept at the enterprises but with GTNet Hub used as cache for making statistical data easier to fetch and allow centralized access to the data. 25 8.3. NON-TECHNICAL REQUIREMENTS 8.3 Non-technical requirements * The system must allow all the domestic trade to be recorded, store information about buyer and seller, species, weight and other fish product properties. * The system must be able to store yield factors and provide users with functionality to verify whether resulted product can be made from specified inputs provided the yield factors are known to the system. * As there are a lot of yield factors, it is difficult to keep them correct, so system should provide a way how to gather statistical information on the yield reported by different participants to allow to make predication models of yield factors. * The system must be able to keep track of mixing and splitting contract/catch/landing notes. That means not only store information about it, but also be able to trace/track which products can be "contaminated" by IUU fish and what catches can specific product contain. * The system must keep track of state in which the fish are in each step ­ frozen, dried, chilled. * Correctness of information about every transaction must be entered into system by the transaction originator and confirmed by the recipient. * Correctness of information about every transaction must be verifiable by the respective authorities and the recipient. * To detect whitewashing, the authorities must be able to verify amount of fish at every step with the originating catches lowered by the yield factors. * The system should be able to establish statistics related to quotas, contract/catch notes, export, production, consumption, waste, yield factors etc. as a way to identify possible IUU fishing. [20] * The system should be able to issue catch certificates at any point of the fish chain to document the legality of the fish received at the issuing actor. [20] 8.4 External prerequisities * Actors joining, splitting or processing fish products need to establish an internal traceability system to keep track of such activities. [20] 26 Chapter 9 Use cases In the use case diagram Figure 9.1 and further text we denote Inspector, Quota Controller, Tax controller and Customs by single super-actor Controller, when distinguishing is not necessary. Use cases * Register catch * Register received fish * Register stock * Register waste * Register sale * Get IUU certificate * Set quotas * Retrieve quotas * Display products chain Support use cases * Create actor mass balance * Check catch validity * Perform mass balance update * Check actor mass balance 27 9.1. REGISTER CATCH 9.1 Register Catch Brief description: This use case has the responsibility to provide an interface into the system for registering any fish catch from the contract/landing note system of fishing company. Actors: Contract/landing note system. Pre-condition: The fish mass is already registered in the contract/landing/batch note system and has thus a unique identification with respect to a specific note. Fishing company has been registered into the system for identification and authorisation. Post-condition: The received fish mass has been assigned a new batch identifier and can be connected with the batch note in the contract/landing/batch note system. The actor has been assigned the fish mass in the system. Extension points: Create actor mass balance. 9.2 Register Received Fish Brief description: This use case has the responsibility to provide an interface into the system for registering any fish received from other actors in the chain. The fish received is to be validated for legality against the IUU Certificates Database. Actors: Fish receiver. Pre-condition: The fish mass is already registered in the certification system (and contract/landing/batch note system) and has thus a unique identification with respect to a note and it is possible to trace the product upstream. Each actor in the fish chain has been registered into the system for identification and authorisation. Post-condition: The receiving actor has been assigned the incoming fish mass in the system. The mass is subtracted from the sender mass to ensure mass balance. The received fish mass has been assigned a new batch identifier if necessary. Extension points: None. 9.3 Register Stock Brief description: This use case has the responsibility to provide an interface into the system for registering any fish in stock at the local actor. The system does not need to keep track of which stock relates to which batch since stock management is the responsibility of the fish actor and should be managed locally. It is however important to keep an account of how much fish is present at the stock. It could, however, be natural to relate the current stock to batches, since it brings additional value in keeping track of the fish. Actors: Fish processor. Pre-condition: The fish mass has already been assigned to batches. Post-condition: The system will know how much fish mass is in the stock. Extension points: Perform mass balance update. 28 9.4. REGISTER WASTE 9.4 Register Waste Brief description: This use case has the responsibility to provide an interface into the system for registering any waste of the received fish mass. The waste reported needs to be related to the batch thus reducing the remaining mass of the actor. Actors: Fish processor. Pre-condition: The outgoing mass has previously been assigned to/registered in batches. Post-condition: The mass balance of the affected batch are updated, i.e., the remaining fish mass of the actor is decreased accordingly. Extension points: Perform mass balance update 9.5 Register Sale Brief description: This use case has the responsibility to provide an interface into the system for registering sale of fish. The sale must be reported against the belonging batch thus reducing the remaining mass of that note for the particular actor. The buyer(s) of the outgoing trade units needs also to be registered to prepare for incoming mass in a new part of the chain. Actors: Fish sender. Pre-condition: The outgoing mass has previously been assigned to/registered in batch. Post-condition: The mass balance of the affected actor is updated, i.e., the remaining mass in the batches is decreased accordingly. Extension points: Perform mass balance update. 9.6 Get IUU certificate Brief description: This use case has the responsibility to provide an interface into the system for issuing an IUU certificate of either received or sent fish. The input into the system is an identifier to batch, trade unit, or cluster. If traceable is directly connected with some batch/contract/landing note, it must have its identifier as identifier to be able to connect it to existing systems. It the traceable is mixed, split or processed, new certificate needs to be issued for resulting traceable(s). The remaining mass coming from previous transformations needs to be within certain thresholds to allow certification. If some of the previous steps has more outcoming than incoming mass times its allowed yield factor, the system will not create a certificate. An IUU certificate can also be issued to receiving parties to ensure legality of the received fish. Actors: Fish receiver, Fish sender, Controller. Pre-condition: The fish is physically received by/sent to an actor registered in the sys- tem. Post-condition: An IUU certificate is created for the batch containing information fulfilling the requirements for the certificate. 29 9.7. SET QUOTAS Extension points: Check catch validity, Check actor mass balance. 9.7 Set quotas Brief description: This use case is responsible to provide an interface to create and modify quotas stored in the system. Actors: Quota controller. Pre-condition: None. Post-condition: Demanded quota is created in the system and (if enabled) begins to be used for checking the catches legality. Extension points: None. 9.8 Retrieve quotas Brief description: This use case is responsible to provide an interface to retrieve and view quotas stored in the system. Actors: Quota controller. Pre-condition: None. Post-condition: None. Extension points: None. 9.9 Display products chain Brief description: This use case is responsible to provide an interface to view previous steps upstream and downstream given identification of single traceable item. It also display properties of all the traceable items on the chain. Actors: Controller. Pre-condition: None. Post-condition: None. Extension points: None. 9.10 Create actor mass balance Brief description: This is a system internal use case with the responsibility to provide an interface to create a mass balance account for the different actors in the system. Actors: Internal. Pre-condition: All actors are already registered or accessible for the system to create an incoming mass balance. Incoming mass is registered as a batch. Post-condition: The actore has been assigned a mass for some fish or fish product. The upstream trade partners of this actor are likewise reduced with the same amount of mass to keep the mass balance in the different parts of the fish value chain. 30 9.11. CHECK CATCH VALIDITY Extension points: None. 9.11 Check catch validity Brief description: This is a system internal use case responsible for checking the validity of the catch registered into the system. The check is either performed against the existing contract/landing note system or internally against the batches representing catch. Actors: Internal. Pre-condition: The catch is registered in the system as batch and linked to the originating catch note. Post-condition: The system either accepts the catch as valid or rejects it as violating quotas. The system can send a message to the fishing authorities related to the acceptance/rejection, and should make the active actor attentive of the issue and how to eventually solve it. Extension points: Retrieve quotas. 9.12 Perform mass balance update Brief description: This is a system internal use case with the responsibility for updating the mass balance account related to specific actor. Any incoming mass is increasing the mass while any outgoing mass is reducing the mass. Actors: Internal. Pre-condition: The actor and incoming batch have assigned a mass. Post-condition: The registering of incoming/outgoing masses updates the remaining mass of the current actor. Extension points: None. 9.13 Check actor mass balance Brief description: This use case is responsible to provide an interface to retrieve actor mass balance and verify it against allowed yield factors stored in the system. Actors: Internal. Pre-condition: None. Post-condition: None. Extension points: None. 9.14 System extension for controlling purposes This use case is optional extension to the basic catch note system for providing functionality for controlling purposes by the fishing authorities. It is a system internal use case responsible for calculating a yield factor distribution based on the data gathered by the system. It can be used for helping authorities to improve system efficiency. 31 9.14. SYSTEM EXTENSION FOR CONTROLLING PURPOSES Figure 9.1: Use case diagram 32 9.14. SYSTEM EXTENSION FOR CONTROLLING PURPOSES Figure 9.2: Certification authority in a chain perspective Figure 9.3: Certification authority in internal perspective 33 Chapter 10 System design 10.1 Schema For deployment diagram of designed system, see deployment diagram Figure 10.1. The designed system has several ways how it can be divided. First, according to clientserver orientation. Client-side components are IUU Certificates Manager, IUU Inspector, IUU Quotas Manager ­ they are done in orange color on the deployment diagram. Server components, marked green, are GTNet Hub, GTNet Access Node implementations (such as TIX), IUU Quotas Database and IUU Certificates Database ­ the former two being already existing software components. According to functionality, we can divide the system into three logical parts: * Storage of the fish products flow in the market chain, which is done by GTNet and actors' internal traceability systems. On the deployment diagram, it is the whole GTNet box together with Actor's Internal Traceability System. * Storage and management of quotas. On the diagram, it is IUU Quotas Database, IUU Quota Manager. * Certification system and verification of legality of catch. On the diagram, it is IUU Certificates Database, IUU Certificates Manager and IUU Inspector. Note, that the orange parts are marked client. In fact, they are client from the view of the rest of the system. From the end-user's point of view, they can be implemented as client-side desktop applications as well as server side web applications. In the later phase of the design, it was decided that they will be implemented as web applications, i.e. server-side. In spite of that, I still mark them as clients, because they are clients to the GTNet, IUU Quotas Database and IUU Certificates database. Moreover, they are applications, that can be replaced by other vendor's implementation when needed without security risk for the system. The `server part' is mission critical, important traceability data are stored there and it is the part which needs to be trusted. This part shouldn't allow unauthorized manipulation with the data. On the contrary, Certificates Manager, Inspector and Quota Manager are merely frontend applications that authenticate to the GTNet and Databases and serve for data manipulation. This is the reasoning behind the non-standard classification. 34 10.2. ACTORS' INTERNAL TRACEABILITY SYSTEMS AND GANS 10.2 Actors' internal traceability systems and GANs In the system, GTNet Access Nodes will be accessed by actors on the fish products supply chain and information from their internal traceability systems will be captured using GTNet Capture Interface. This thesis will not cover the way how internal traceability system should work neither on physical level nor in software. It should capture properties listed in Appendix B. Each actor's internal traceability system will supply its own TIX with internal traceability data and incoming/outgoing shipments using GTNet Query Interface. The data will follow format defined by Traceability Resource Definition defined further. Fish products shipping, retrieving and modifying can be modeled using means of TraceTracker Data XML, i.e. batches creation and destruction, entering and leaving clusters (e.g. for transportation), batches joining, batches mixing (e.g. mixing two catches or creating product from fish) and splitting (e.g. shipping part of the catch), converting (e.g. when somebody processes the fish without actually adding/removing anything). There must be special type of batch for waste. Waste can be modeled using TraceTracker Data XML by splitting batch into two new ones one for the processed product, the second for waste. From these data in actors' GANs, IUU Certificates Database component shall be able to access the data, compute yields factors and identify using yield factors and Quotas Database which goods is suspicious not to be legal. With basic operations supported by TT Data XML, we can cover following use cases: * Register received fish * Register sale * Register mix/split of notes * Create batch note If we define special type of cluster or batch property for stock and waste, we can also control stocks of each actor, covering use cases: * Create actor mass balance * Register stock * Perform mass balance update * Register waste 35 10.2. ACTORS' INTERNAL TRACEABILITY SYSTEMS AND GANS 10.2.1 IUU Quotas Database It will be an XML database which is able to store set of restrictions imposed upon fishing market. Types of restrictions which needs to be stored in the database is described in Section 10.4. The Database will be administered using IUU Quota Manager and used by IUU Inspector for deciding about legality of catches. The quotas will be described using XMLbased language and communication will be mediated by QCI and QQI that will be designed and described later. This will cover following use cases: * Set quotas * Retrieve quotas 10.2.2 IUU Certificates Database It will contain list of identifiers of outgoing batches (the other properties will remain stored in the GTNet) and certificates assigned to them. When any actor asks for a new batch to be registered, IUU Certificates Database will be asked for certificate generation. It will query its GTNet Access Node for the rest of the batch information, then query IUU Quotas Database and find out if the batch hasn't violated any of the rules stored in there and if the batches one level up already have their own certificates. If it succeeds, it will store information about certification of respective batch and send digitally signed reply to the actor who asked for the certification. If the batch has already certification information stored in the IUU Certificates Database, it will send the response immediately without further verification. This will cover following use cases: * Get IUU certificate * Check note validity 10.2.3 IUU Certificates Manager It will be used by fish market actors to ask for certificates to their own shipments (outgoing batches) and verify certificates of incoming batches. It only needs to be able to ask for certification, ask for certificate, verify certificate's signature. This will cover following use cases: * Get IUU certificate 36 10.3. CAPTURING NOTES IN THE SYSTEM 10.2.4 IUU Inspector It will be used by both national inspectors and commission inspectors to monitor the fish market and fulfilling of regulations. It should be able to query IUU Quotas Database and display and filter quotas, retrieve and verify certificates from IUU Certificates Database (using QQI), and monitor the chain step by step using GQI against its GTNet Access Node. This will cover following use cases: * Retrieve quotas * Get IUU certificate * Display products chain 10.2.5 IUU Quotas Manager It will be used by national inspectors to set and manage quotas for their region. It will communicate with IUU Quotas Database using QCI. This will cover following use cases: * Set quotas * Retrieve quotas 10.3 Capturing notes in the system We decided not to keep track of the batch/contract/landing notes in the system. For verifying yield factors and quota conformance, we do not need to know from which note the fish is. This decision was made to make the system simpler, and fit it into the way how GTNet works now. We do not need to verify legality of notes. Instead, it is simply enough to find out legality of specific catch or recognize place where some illegal fish was added into fish product. In case we need to verify the original note, there can be connection between catch and note, which will provide note identifier pointing out to external system. 10.4 Quotas From various sources, we have gathered list of properties which can be used for deciding what catch is legal. Example of such rule: Bottom trawling and fishing with static gear, including bottom set gillnets and long-lines should be prohibited within the NEAFC Regulatory Area enclosed by sequentially joining with rhumb lines the following positions). There may be exceptions allowed from these rules. 37 10.4. QUOTAS For more information, see [34]. According to these needs, XML based language for describing these restrictions will be created and used in Quota Capture Interface and Quota Query Interface. * vessel's ownership, resp. fisherman's license to fish * length of vessel used for catch ­ ships exceeding certain length may have fishing forbidden in some areas * type of vessel [35] * track of the vessel (may be tracked by satellite) * sea depth * if the area is under national fisheries jurisdiction * allowable catch for given area * allowable catch for given country [35], allow share-out of the joint quota, allow subsequent adjustments * some combination of the rules above, e.g. areas where certain combination of method of fishing, type of ship, time period when it's are regularly (dis)allowed [35] 10.4.1 Generic quotas model 10.4.1.1 Master data Master data is data that remains unchanged over a period of time. [4] We use them for describing actors and other things which are mostly of static nature. They support transactional processes and operations, but they themselves are non-transactional. We have identified following entity types for our master data, together with their at- tributes: Owner Owner is any person or company that owns some vessel which is used for fishing. id name country Example of XML element describing owner: nl456 Nordlaks no 123456 38 10.4. QUOTAS Vessel type Vessel type is used to categorize vessels for the purpose of defining fishing quotas. * id * name (language dependent) * description (language dependent) Example of XML element describing vessel type: trawler Trawler Vessel Vessel is any ship or boat which is used for fishing, no matter under which state's jurisdiction it is. (I.e., it may be useful sometimes to include even ships of states which do not demand electronic traceability.) * id * owner (reference) * type * length (in metres) Example of XML element describing vessel: NLV345 nl456 trawler 35 Net type Net type is used to categorize fishing nets for the purpose of defining fishing quotas. * id * name (language dependent) * description (language dependent) Example of XML element describing net type: 39 10.4. QUOTAS pelagiclongline Pelagic longline Long line net with baited hooks used near the surface Area Area is a particular geographical region with specified boundary, for which quotas are set separately. * id * geographical coordinates * minimal depth (in metres) * state of jurisdiction Example of XML element describing area: BS123 Baltic sea 250 int Species Species is a taxonomic group of fish or other biological group which we want to distinguish for the purposes of regulating its catching. * id * name (language dependent) Example of XML element describing species: atlanticcod Atlantic cod Torsk Treska 40 10.4. QUOTAS Quota Quota is a description of some legal restriction or set of restrictions imposed on fishing, which we want to use for monitoring whether those restrictions are obeyed. * id * enabled * allowed (boolean value describing whether this is quota banning something or creating an exception by allowing something) * validityFrom (YYYY-MM-DD according to ISO 8601) * validityTo (YYYY-MM-DD according to ISO 8601) * expression describing quota (will be described later) Examples of XML element describing quotas: 001-longline-in-shallow-water true false 2009-01-01 2009-12-31 longline 200 002-max-weight-nordlaks true false nordlaks 800000 10.4.1.2 Transactional data Transaction data is data describing an event (the change as a result of a transaction) and is usually described with verbs. Transaction data always has a time dimension, a numerical value and refers to one or more objects (i.e. the master data). [31] 41 10.5. CERTIFICATION SYSTEM Catch Catch is some amount of fish (or other biological group) of a single species, which is caught during one or more catches (activity of catching) at one day and one area by one vessel. * id * vessel (reference) * net type (reference) * area (reference) * species (reference) * date * weight (in kilograms) Because of its transactional nature, catches will be stored in GTNet and thus should follow TraceTracker Data XML format. Example of such catch definition: NLV345 pelagiclongline BS123 salmon 450 10.5 Certification system The whole system's main purpose is to provide some sort of certification that specific products do not contain illegally caught fish, so that other actors can verify that they are buying legal product. This part will describe the idea behind the certification system in more details. There are parts of the system, which are under supply chain actors' control and parts which are not. Quota database will not be under supply chain actors' control neither, it should be accessible only by the authorities that are interested in preventing fraud. The certificates database is the part that decides the (il)legality of product based on external request. It's task is to check the GTNet for the previous steps, verify their certificates (in case it's not a catch), look up quota database for the additional restrictions (fishing quotas and restrictions as well as maximum yield factors), verify if they were not violated and store the certificate and send it to the requester in a form, whose authenticity can be verified. The only element in this system which is partially under supply chain actors' control is GTNet (it's GANs, respectively), so they can cheat there e.g. by faking information about net sizes, 42 10.6. USER INTERFACE areas of fishing etc. Each actor has, of course, write access only to his part of traceability information. There are two kinds of information which will be looked up in the GTNet ­ information about catches which will be used for checking if the quotas are obeyed and subsequent products flow, which will be monitored for yield factors to ensure that no unreported catches enter the chain. We can prevent faking these data in different ways. * Catches ­ if we don't want vessels to be under non-stop surveillance of some inspectors (which is possible, but probably will be found uneconomical) then this issue can be solved by random auditing by authorities' inspectors. It means that except those verified certificates there may be certificates which are unverified and thus not ensuring legality of the catch. This can still make it acceptable for trade, but it should at least allow the system to propose the authorities parts of the chain which should be audited. Random auditing in lots of cases, where the market is big so everything cannot be verified by real person, is good trade off between deterring a checking of actors and costs. We do not need to make analysis of how exhaustive the auditing should be, as this can be made at any time during the system operation, resulting at changes in respective policies. * Products flow ­ The only way how cheating can be done easily and without much risk is during processing where the processor creates some amount of waste. He can add IUU fish in case it does not result in exceeding his allowed yield factor. In case the yield factors are set well, this makes it still easy to introduce IUU fish but much less profitable for the businesses, because only very small amount can be introduced. In case this still remains significant problem, random auditing at fish processors can be introduced, for example checking that all the stock fish of that actor are already reported in the GTNet. 10.6 User interface 10.6.1 Design decisions The first decision which we must deal with is whether to provide users with desktop application or create web-based user interface (UI). Desktop application UI * Pro: Best responsiveness. * Pro: In desktop GUI toolkits, the interface can be created more easily both if one is creating the interface manually or using some WYSIWYG creator. For desktop toolkits there is wider choice of such builders. * Cons: Very low control of which versions of our applications users have installed. 43 10.6. USER INTERFACE * Cons: It is necessary to keep all the interfaces between frontend (UI) and backend (databases, GTNet) backwards compatible or at least keep them for a long time so that users have enough time to upgrade existing installations. Web-based UI * Pro: Complete control over versions which users are using, thus we do not have problem with changing APIs between parts of the system when needed. * Pro: Easier support due to possibility of adding more debugging information and tracing what user with troubles is doing with the application. * Cons: Less responsive. * Cons: More data needs to be transmitted. As the applications will be used in corporate environment and by state authorities, the not breaking compatibility between parts of the system and good support is crucial, the web based interface fits into our needs much better. Lower responsiveness can be improved by using AJAX for fetching only data that is really needed when querying data ­ more or less the same data that desktop application would need to fetch. Moreover, with the last versions of major web browsers, the JavaScript engines speed has improved significantly, so the difference would be small enough. 10.6.2 Frameworks and Toolkits For implementing the user interface functionality, there is a large variety of frameworks and libraries which are meant to help us with the implementation. The most important aspects for our purposes are * the easiness of use, * good maintainability of the result, * good interactivity provided implementing parts of the functionality on client-side and sending only requested data, without need to refresh the whole web page (this can be achieved for instance by using AJAX, JSON or Macromedia Flash), * open solution. As candidates, we have selected following toolkits: * Java Server Faces 1.2 (JSF) * Google Web Toolkit (GWT) * JBoss Seam (builds on JSF) 44 10.6. USER INTERFACE * Echo3 * Wicket * RichFaces (JSF extension) 10.6.3 Evaluation 10.6.3.1 Java Server Faces * Web framework for component based development. * Widely used, so enough implementations and modules are available. 10.6.3.2 Google Web Toolkit * Developed by Google for usage in their own applications. * Licensed under the Apache License version 2.0. * Fast AJAX applications without need to solve browser-dependent issues. * Well documented. * Handles user interface part of the application (viewer). 10.6.3.3 JBoss Seam JBoss Seam combines the two frameworks Enterprise JavaBeans (EJB3) and JavaServer Faces (JSF). You can easily access any back-end EJB component from the front-end by addressing it by its Seam component name. JBoss Seam introduces the concept of bijection, taken from Spring's dependency injection feature where objects can be in-jected or out-jected to/from assigned variables using the @In and @Out annotations. Seam also expands the concept of contexts. Each Seam component exists within a context. The default Seam context is conversation. A conversation can span multiple pages and usually spans the whole business flow, from start to finish. The session context captures all actions of a user until he logs out or closes the browser ­ even multiple uses of the browser back-button. [30] 45 10.6. USER INTERFACE 10.6.3.4 Echo3 * Brings event-driven development to web applications. * Allows creating GUIs in a way very similar to Swing. * The GUI is rendered using JavaScript and using AJAX the state is synchronized with the server side, allowing to create more desktop-like application for web browser. 10.6.3.5 Wicket Source: [32]. * Web framework for component based development, similar to JSF. * Uses plain XHTML for templating, thus enforcing separation of presentation layer from business logic. * Each component is backed by its own model, which represents the state of the component. The framework does not have knowledge of how components interact with their models, which are treated as opaque objects automatically serialized and persisted between requests. More complex models, however, may be made detachable and provide hooks to arrange their own storage and restoration at the beginning and end of each request cycle. Wicket does not mandate any particular objectpersistence or ORM layer, so applications often use some combination of Hibernate objects, EJB beans or POJOs as models. 10.6.3.6 RichFaces Rich component library for JSF built on open source framework Ajax4jsf, allowing easy integration of AJAX capabilities into Java web applications. [17] * Licensed under GNU Lesser General Public License * AJAX-enabled applications without need to solve browser-dependent issues. * Provides components (such as trees) that can be used in both classic static way, sent with all the data to client and operated using javascript, or filled by data using AJAX. * No need to program JavaScript code manually or handle CSS. * Easy skinnability. It provides properties which allow user to customize each skin, so theming can be done flexibly while still maintaining consistent look-and-feel with very little additional effort. 46 10.6. USER INTERFACE 10.6.4 User interface design In this chapter, we show and describe designed user interface using screenshots and/or layout mockups. 10.6.4.1 IUU Certificates Manager Following images Figure 10.2, Figure 10.3, Figure 10.4, Figure 10.5 describe IUU Certificates Manager user interface. 10.6.4.2 IUU Quotas Manager Following images Figure 10.6, Figure 10.7 describe IUU Quotas Manager user interface. 10.6.4.3 IUU Inspector Following images Figure 10.8, Figure 10.9 describe IUU Inspector user interface. 47 10.6. USER INTERFACE Figure 10.1: Deployment UML diagram 48 10.6. USER INTERFACE Figure 10.2: IUU Certificates Manager ­ main screen Figure 10.3: IUU Certificates Manager ­ trade unit lookup 49 10.6. USER INTERFACE Figure 10.4: IUU Certificates Manager ­ negative response Figure 10.5: IUU Certificates Manager ­ positive response 50 10.6. USER INTERFACE Figure 10.6: IUU Quotas Manager ­ main screen Figure 10.7: IUU Quotas Manager ­ main screen with selected quota 51 10.6. USER INTERFACE Figure 10.8: IUU Inspector ­ main screen with business lookup opened Figure 10.9: IUU Inspector ­ business view with incoming/outgoing trade units and batches in production 52 10.6. USER INTERFACE Figure 10.10: IUU Inspectors ­ selected traceable item 53 Chapter 11 Implementation 11.1 Traceability Resource Definition Based on chapter Section 10.2 and properties identified in Appendix B Traceability Resource Definition that can be used in captured fish market was created. It can be found among attached source files xml/fish-trd.xml. Part of the definition follows. Fish products traceability information for the purposes of monitoring of IUU fishing. AI 01 GTIN AI 10 Batch no. . 54 11.2. QCI ­ QUOTA CAPTURE INTERFACE . . Captured fish - trade unit when at vessel . . . 11.2 QCI ­ Quota Capture Interface Quota Capture Interface is an interface we drafted for importing quotas and necessary data it relates to (fish companies, vessels, fish species, etc.) It uses a simple protocol built on top of HTTP. Basic properties of the service of QCI * The service follows a simple request / response scheme. * It is synchronous, so that the client will not get a response until the service has completed processing of the request. * A request constitutes a transactional unit, so that all the data in one request are saved using the same transaction. * The data in a request is either accepted as a whole, or rejected as a whole. That is, a single error in the data will cause the entire request to fail and no data, even the correct parts, will be imported. 55 11.3. QQI ­ QUOTA QUERY INTERFACE * Duplicate data elements, either internally in the request, or duplicates of what already resides in the database, are rejected. This this is not considered an error and so it does not cause the import to fail. * Request processing stops at the first error. The error is reported back to the client. The client sends XML file via HTTP and server replies with HTTP status code ­ 200 for success, one of 4xx codes for request error, one of 5xx codes for internal server error. For description of status codes, see Section C.2. XML Schema for client server queries is included in Section C.1. Example of such request is included too. 11.3 QQI ­ Quota Query Interface Quota Query Interface is an interface we drafted for querying quotas and necessary data it relates to (fish companies, vessels, fish species, etc.) It uses a simple protocol built on top of HTTP which follows a request / response scheme. The client sends XPath query as plain text via HTTP and server replies with HTTP status code (200 for success, one of 4xx codes for request error, one of 5xx codes for internal server error) and XML file with respective data. For description of status codes, see Section D.2. XML Schema for data stored on server is included in Section D.1 It is actually very similar to the schema used in QCI and it restricts the data which client then queries using XPath. In the request URL, protocol version number is passed as GET parameter. Example of such request using QQI is included too. 11.4 CertQI ­ Certificates Query Interface Certificates Query Interface is an interface we drafted for certificates retrieval. It uses a simple protocol built on top of HTTP which follows a request / response scheme. The client sends simple XML uery via HTTP and server replies with HTTP status code (200 for success, one of 4xx codes for request error, one of 5xx codes for internal server error) and XML file with respective certificate. For description of status codes, see Section D.2 (they are the same as for QQI). XML Schema for data stored on server is included in Section E.1 In the request URL, protocol version number is passed as GET parameter. Example of such request and response using CertQI is included too. 56 Chapter 12 Conclusion In this paper, we have explained the area of food traceability, electronic traceability and focused on specifics of the traceability of fish products. We have provided a description of the problem of illegal fishing, regulations of fish market and clarified how this can be tackled by the means of electronic traceability. Existing software traceability solution was described and it was laid down how this can be used for implementing solution for verification of fish products origin and legality. Based on these requirements, the system structure was designed and interfaces between parts of the system were defined. We created traceability resource definition for the GTNet so that the domain specific traceability can be carried out. Software user interface was prototyped. The backend (Quotas Database and Certificates Database) used by the JSF frontends does not exist at the moment nor has it been decided which technologies will be used it but it will most probably be based on some variant of XML database. In the current state, the software can be used to present the way how the IUU fishing can be handled and how do we expect users to interact with such system. Designed interfaces also allow participating enterprises to either develop their own user frontend application should they for instance require to integrate into existing information system, or they can use interfaces for automated processing of their data ­ CertQI lends itself to being integrated with existing information systems of enterprises. To get the system into production, the data storage and business logic in Quotas Database and Certificates Database have to be implemented. The user interfaces can be polished and should be subject to usability testing with the target audience. 57 Appendix A Illustration images and schemas Figure A.1: Example of food chain traceability [22] 58 Appendix B Data needed for fish traceability This appendix's main source: [13] B.1 Captured fish B.1.1 Vessel UCC/EAN-128: * AI 01 GTIN * AI 10 Batch no. * AI 310X Net weight * AI 11 Catch date (optional) * AI 414 Vessel id (optional) HUMAN READABLE: * Scientific name * Commercial name * Catch area * Production method * Preservation * Size of fish * etc. B.1.2 Auction/collector * the same as vessel * AI 412 GLN (optional) 59 B.1. CAPTURED FISH B.1.3 Processing/wholesale UCC/EAN-128: * AI 01 GTIN * AI 10 Batch no. * AI 310X Net weight * AI 412 GLN * AI 11 Catch date (optional) * AI 13 Package date (optional) * AI 15 Best before date (optional) HUMAN READABLE: * Scientific name * Commercial name * Catch area * Production method * Treatment * Preservation * Storage temperature * Size of fish * etc. B.1.4 Retail * GTIN HUMAN READABLE: * Commercial name * Production method * Catch area 60 B.2. FARMED FISH * Batch number * Best before date * Net weight * Preservation * etc. B.2 Farmed fish It should be noted that fish farming is in general very similar to industrial production. It is thus possible to control and document each step of the process. This makes traceability possible from the consumers all the way back to the parents of the fish and to the eggs they produced. In addition data on the food used and any medication applied during the growing process is available. This is different to captured fish where it is not possible to determine any history prior to the point of capture of the fish. Capturing data for farmed fish was decided not to be in the scope of this thesis, so I will only reference them. Data needed for labeling for upstream market can be found in [13], pages 26-31, the same for downstream market in [13] pages 32-36. B.3 Transport * AI 00 SSCC * AI 02 GTIN of the contained trade item * AI 37 Count of trade item OPTIONAL: * GLN of the supplier (AI 412) * GLN of the vessel or physical location (AI 414) * GLN of the receiver (AI 410) * Gross weight (AI 330X) 61 Appendix C QCI definitions C.1 QCI XML Schema XML Schema used for Quota Capture Language used in Quota Capture Interface. 62 C.1. QCI XML SCHEMA 63 C.1. QCI XML SCHEMA 64 C.1. QCI XML SCHEMA 65 C.1. QCI XML SCHEMA Example of request using Quota Capture Interface. 66 C.1. QCI XML SCHEMA POST /qdb/qci/request?version=1.0 HTTP/1.1 Host: somehost:someport Content-Type: text/xml; charset=UTF-8 Authorization: Basic XXXXXXXXXXXXXXXXXX nl456 Nordlaks no 123456 trawler Trawler seiner Seiner NLV345 nl456 trawler 35 pelagiclongline Pelagic longline Long line net with baited hooks used near the surface seine Seine Seine net description 67 C.1. QCI XML SCHEMA BS123 Baltic sea 250 int atlanticcod Atlantic cod Torsk Treska bluewitning Blue Whiting Kolmule salmon Salmon Laks Losos 001-longline-in-shallow-water true false NLV345 longline 200 002-max-weight-nordlaks true false nordlaks 8000 68 C.2. QCI STATUS CODES C.2 QCI status codes 200 Successful import 302 Moved Temporarily (e.g. redirection to secure port) 400 Missing required parameter. 401 Authentication failure (e.g. bad username or password) 403 Insufficient privileges 404 Sub-service not found (e.g. misspelling the path name) 405 Method not allowed (e.g. using GET instead of POST) 413 Request entity too large. The size of the submitted XML file or binary data exceeds the maximum allowed size. 450 XML parsing error. The XML document contains structural errors. Either it does not comfirm to the required XML Schema or missing required elements. 455 Logical data error. Returned if the submitted data contains logical er- rors. 500 Internal server error (system failure) or undiagnosed client errors (e.g. database server not available) 503 Service temporary unavailable (e.g. service is overloaded and unable to process the request) Table C.1: 69 Appendix D QQI definitions D.1 QQI XML Schema XML schema used for responses in Quota Query Interface. 70 D.1. QQI XML SCHEMA 71 D.1. QQI XML SCHEMA 72 D.1. QQI XML SCHEMA 73 D.1. QQI XML SCHEMA Example of query using Quota Query Interface. POST /qdb/qqi/query?version=1.0 HTTP/1.1 Host: somehost:someport Content-Type: text/plain; charset=UTF-8 Authorization: Basic XXXXXXXXXXXXXXXXXX /data/quota[xs:date(validityFrom) gt xs:date("2000-01-01")] 74 D.2. QQI STATUS CODES D.2 QQI status codes 200 Successfully found 302 Moved Temporarily (e.g. redirection to secure port) 400 Missing required parameter. 401 Authentication failure (e.g. bad username or password) 403 Insufficient privileges 404 Sub-service not found (e.g. misspelling the path name) 405 Method not allowed (e.g. using GET instead of POST) 413 Requested result too large. Server was unable to process the query. 450 XPath query syntax error. 500 Internal server error (system failure) or undiagnosed client errors (e.g. database server not available) 503 Service temporary unavailable (e.g. service is overloaded and unable to process the request) Table D.1: 75 Appendix E CertQI definitions E.1 CertQI XML Schema XML schema used for responses in Certificates Query Interace (CertQI) 76 E.1. CERTQI XML SCHEMA Example of query using CertQI POST /cdb/certqi/request?version=1.0 HTTP/1.1 Host: somehost:someport Content-Type: text/xml; charset=UTF-8 Authorization: Basic XXXXXXXXXXXXXXXXXX (02)7080000728152(10)2005-312(21)0004 1 Example response (02)7080000728152(10)2005-312(21)0004 Salmon fillets Salmon fillets 3000 SUSPICIOUS yield factor over limit (01)7080000728152(10)2005-312(21)0001 Salmon catch Salmon catch 1000 VERIFIED (01)7080000728152(10)2005-312(21)0002 Salmon catch Salmon catch 1000 VERIFIED (01)7080000728152(10)2005-312(21)0003 77 E.1. CERTQI XML SCHEMA Salmon catch Salmon catch 1500 VERIFIED 85 75 78 Bibliography [1] Marshall, P. and AquaTT Ltd.: Traceability Module. AquaTT Student Workshop 2004, AquaTT Ltd., 2004, . 2.2 [2] Senneset, G. and Fors, E. and Fremme, K.: Challenges regarding implementation of electronic chain traceability, British Food Journal, 2007. 3.4 [3] Pedersen, H.: Curbing IUU fishing: the status in Norway, Ministry of Fisheries and Coastal Affairs, 7 August 2006, . 7.1 [4] Wills, L.: Ask The SAP Expert: Questions & Answers, 2007, . 10.4.1.1 [5] European Commission: About the Common Fisheries Policy: Managing a common resource, European Commission, January 2009, . 5 [6] European Commission: About the Common Fisheries Policy: Management of resources and environment, European Commission, August 2007, . 5 [7] European Commission: Commission proposes to stamp out pirate fishing, European Commission, 17 October 2007, . 5.2 [8] European Commission: About the Common Fisheries Policy: Regional fisheries organisations, European Commission, December 2007, . 5.1 [9] EPCglobal: EPC Information Services (EPCIS) Version 1.0.1 Specification, EPCglobal, 2007, . 6.2 [10] EU Food Law 178/2002. 2.3, 2 [11] Directorate General for Health & Consumer Protection: Factsheet: Food Traceability, Directorate General for Health & Consumer Protection, June 2007, . 2.3 79 [12] Norwegian Ministry of Fisheries and Coastal Affairs: What is IUU fishing?, . 2.1 [13] GS1: Traceability of Fish Guidelines: Application of EAN-UCC standards in implementing EU legislation and business requirements regarding consumer information and traceability, GS1, 7 November, 2002, . 2.2, 7.1, B, B.2 [14] GS1: The GS1 Traceability Standard: What you need to know, GS1, January 2007, . 3.1, 3.2, 3.3, 3.2, 3.3, 3.4, 3.4 [15] GS1: GS1 website, . 3.1 [16] International Organization for Standardization: ISO 8402:1994 ­ Quality management and quality assurance ­ Vocabulary. 2.2 [17] JBoss: JBoss RichFaces webpage, . 10.6.3.6 [18] European Parliament: Regulation (EC) No 178/2002 of the European Parliament and of the Council, 28 January 2002, . 1, 2.2 [19] Reinertsen, O.: EU to close the EU market to all untraceable fishing products, TraceTracker Innovation ASA, 18 October 2007, . 5.2 [20] Srensen, C. and Bjrnson, F. and Fors, E.: Practical and Technological challenges for introduction of electronic traceability systems related to IUU, SINTEF, 29 April 2008. 7.1, 7.2.3, 7.3, 8.2, 8.3, 8.4 [21] SEAFOODplus-web: SEAFOODplus webpage, . [22] SINTEF Fiskeri og havbruk AS: System for tracing food, 8 June 2007, SINTEF Fiskeri og havbruk AS, . A.1 [23] TRACE: TRACE project webpage, . 6.1 [24] TraceTracker Innovation ASA: Technical Architecture Whitepaper, version 1.4, 27 October 2006, . 4.2 [25] TraceFish: TraceFish webpage, . 6.1 80 [26] US Public Health Security and Bioterrorism Preparedness and Response Act of 2002. 2.3 [27] Wikipedia: Common Fisheries Policy, 15 May 2009, . 5 [28] Wikipedia: EPCglobal, 1 March 2009, . 6.2 [29] Wikipedia: EPCglobal Network, 27 March 2009, . 6.2 [30] Wikipedia: JBoss Seam, 29 March 2009, . 10.6.3.3 [31] Wikipedia: Transaction data, 4 December 2008, . 10.4.1.2 [32] Wikipedia: Wicket, 1 March 2009, . 10.6.3.5 [33] Blueyou LTD: Benchmarking Study on International Aquaculture Certification Programmes, World Wildlife Fund (WWF) Switzerland and Norway, Zurrich and Oslo 2007, . 2.2 [34] Commission of the European Communities: Council regulation. Establishing a Community system to prevent, deter and eliminate illegal, unreported and unregulated fishing, 2007, . 10.4 [35] North East Atlantic Fisheries Commission: Management Measures Currently in Force, . 10.4 81