# Towards a Reference Architecture for Cargo Ports
###### Abstract
Our objective is not to define an RA for any type of CPS, but we will consider a specific type of system, a transportation system, specifically a maritime container cargo port. As we discuss in Section 7, an analysis of the relevant literature found that there are not many reference architectures for cargo ports ([9] and Section 7). We show here a cargo port RA built of patterns described using  
Figure 1: A cyber-physical system. UML models. We consider this effort the first attempt to define a precise and semiformal architecture for these systems. We believe that an abstract, semiformal approach is the most practical design approach given the complexity of the systems we are considering. That is not to say that parts of the architectures cannot be formally modelled; UML models can be complemented with formal descriptions such as OCL [10], and with them, we can make this architecture more formal if needed [11]. Furthermore, patterns and RAs can be converted into ontologies, which are even more precise descriptions and allow for proving some formal properties [12]. Note that for CPSs, it is also possible to define reference architectures that include several levels [4, 13, 14]. The lower levels of those architectures have many common aspects, but we are concerned only with the semantic aspects of port operations, so we will focus only on the higher levels. We first assemble a set of process patterns (a CPS process describes a physical process, e.g., the purification of water). A software process is more general; it describes a sequence of steps to accomplish some objective, e.g., teaching a course. Here, process patterns (which describe software processes) describe the functions performed by cargo ports. These patterns include _ship arrivals and departures_; _port drayage_ (the transport of containerized cargo by specialized trucking/railway companies between a maritime port terminal and an inland distribution point or a rail terminal [15]); _container terminal physical structure_ (the physical units used in the port); and _port loading/unloading_ (the activities of loading and unloading containers) [16]. Each process pattern includes one or more use cases. A use case represents a complete interaction between the users and the system; each use case is associated with a set of actors that correspond to some of the stakeholders of the system. The complete patterns have been published in conferences; we show here only their important sections; some have been modified. These patterns result in a partial RA for a cargo port. We used this architecture as the basis for a security reference architecture, where defenses against identified threats have been added [17], so this article is a complement to that article. We make it clear that we are not presenting a model for a specific port or type of port. Patterns and RAs are generic models intended for system and software designers. Our models are abstractions of fundamental aspects found by studying the structure and operations of several cargo ports around the world. Because of this, regulations, standards, and trade models (e.g., single-window strategy) are not relevant. A complete model is also beyond the possibilities of two people, so this is a partial model, and we do not claim this model to be complete. Our contributions include:  
* A set of process/structure patterns that describe the functional aspects of a reference architecture for cargo ports. These patterns describe semantic aspects found in any cargo port and can be adapted or extended to describe other CPSs. * A decomposition of the cargo port process patterns into use cases that describe its actor interactions with the system. The use cases are dynamic models that complement the structural models of the port. * A partial reference architecture that shows how to integrate these process patterns with structural patterns, indicating the typical stakeholders found in all ports. We know of no other reference architecture for cargo ports (see Section 7).