Keywords

1 Introduction

The idea of open systems has been placed with increasing acuity wherein the need for new services and their supporting processes require overall integration of a disparity of systems. By open system within a framework of complex information systems (IT-Systems) is understood by a system (of systems) in which its subsystems implement a responsibility framework, or set of computational capabilities, where for each of those subsystems there are at least two implementations that compete in the market. In an architectural service oriented framework it could be considered that each subsystem implements a set of services whose interface corresponds to an open specification or even a norm when a specification is required by a formal standardization [12].

The generalization of sensors/actuators as intelligent systems with an increasing degree of autonomy, adaptability and may be permanently connected, has motivated a number of works in the area of Internet of Things (IoT), [1]. As defined in [1], “The Proliferation of These Devices in the Communicating-actuating Network Creates the Internet of Things (IoT),…”, which means that the growing number of networked devices form the growing capacity and distributed intelligence in the perception of environment where devices are always connected to any decision system (IT-System).

Although expectations are high concerning the widespread potential adoption of a network of “things”, the success depends on the establishment of a “business ecosystems” as a multiplier of devices installed settling the contribution to the development of Big-Data concepts in supporting business and decision processes. Although being a recent topic, the first use with the designation of network of things (IoT) dates back to 1999–2002 being referred in the Forbes Magazine as “We need an internet for things, a standardized way for computers to understand the real world” as an interaction strategy with the real world [2]. In the same paper is identified a set of capabilities that could help reduce the gap between the physical and virtual worlds:

  • Communication and cooperation - either among different units in close spaces or in communication/cooperation with the infrastructure side systems in connection to central information systems (back-office). Recent developments in technologies such as GSM/UMTS/LTE, Wi-Fi, Bluetooth, ZigBee, DSRC-MDR (Dedicated short-range communication – Medium Data Rate), Sigfox, NFC (Near Field Communication), among others, has established facilitators (production capacity and costs) in the generalization of devices, with more potential to incorporate more functionalities;

  • Addressing capability (Addressability) - the devices must be able to be addressed for what a reference must be located (sought) in any directory or by any search (discovery/lookup) process with or without the use of a centralized repository (peer-to-peer);

  • Identification - looks for an agreement under a unique identification framework or through any qualification that allows the conflict resolution between identical addresses;

  • Sensing - collection of information about the physical environment, its local store and forward for information systems when available a communication channel for this purpose (adaptive communication);

  • Actuation - generation of actuation signals over physical systems, where such a responsibility could require a processes coordination with local autonomy (in a framework of Programmable Logical Controllers - PLC);

  • Embedded information processing - the increasing ability of processors provided by Advanced RISC Machine (ARM) architectures, allow the incorporation of local intelligence;

  • Location - the emergence of intelligent “things” with localization capabilities either by geo-positioning (GPS/EGNOS) or by identification from stations in the infrastructure, being the accuracy of the positioning dependent on the triangulation techniques used;

Thus, this paper aims to be a contribution to an open architecture of logistics and transport processes management system, as a model of an open integrated systems, being defined a computational responsibility associated with the embedded system (on-board) as well as a reference implementation (prototype) of a host system to validate the interface. The idea is that the embedded subsystem can, natively, be prepared to cooperate (cooperative systems [11]) with other on-board units and with systems in an infrastructure commonly referred to as a center information system or back-office. The interaction under a framework of cooperation between equals (peer-to-peer) can occur through a virtual connection point to point communication. In interaction with a central system the proposal is to adopt an open framework for cooperation where the embedded unit or the unit placed somewhere on land or sea environment, which has been called the Mobile Services Unit (MSU), interacts in response to a set of implemented capabilities in cooperation with a monitoring infrastructure ensuring its operability and response in case of failure (prognosis). This research presents the results from the SASPORT project, namely the nomadic unit (MSU) as an initial prototype.

The paper is organized as follows: Sect. 2 provides a discussion about open interfaces for communication; Sect. 3 describes the proposed approach architecture; Sect. 4 presents the concluding remarks and highlights few future lines of research.

2 Open Interfaces for Communication

This section is concerned with the establishment of a theoretical framework that underpins the architectural options, with special emphasis on scientific and technological work streamlined by the scientific community and industry, in promoting heavily based solutions in electronics, telecommunications and computer and information systems, in an open architectures framework for communication between devices and a host (the central of back-office system). In fact the trio, people, “things” and Internet can be connected via mediators’ devices as shown in Fig. 1.

Fig. 1.
figure 1

The Smartphone as a mediator between people, “things” and Internet [2].

Full size image

Although the devices tend to be simple and specialized, either in the number of sensors/actuators or in the computational and communication resources, the trend with the increasing competitiveness at the hardware level is to implement increasingly intelligent and autonomous units or “things” [3].

However, all this potential requires the definition of a set of open specifications and even the definition of new standards so that the devices within a framework of IoT can participate in transport processes, logistics, decision support approaches and others. As a strategy to respond to the increasing network complexity of smart devices [4] and [5] proposes a network management architecture of intelligent “things” through a multi-agents architecture. The architecture presented and discussed in [4] and [5] was framed in the project called Platform for Transport Management Systems (P4TMS) considering the transport of goods in an inter-modal way. The P4TMS aimed at the management of transport processes involving multiple modes (road and rail). The models of a transport process includes activities and their interdependencies. An activity involves one or more services under a pre-established contract celebrated by a service provider that implements an open interface. A service provider is referred to as its implementation and its operationalization through a computational agent (intelligent entity or not). Thus, in a services oriented architecture, all are services, being understood as computational entities with which other services can establish dependency relationships.

Although one of the platform’s goals was an agile response (intelligent) to transport planning and associated logistics, the platform aspect most closely with this paper’s topic refers to the network management methodology of devices that is intended to be adaptive and intelligent. Thus, we propose a component, as another IT-system with the management responsibility of a network of devices through the implementation of a component called intelligent Transport Unit (iTU) Technological Infrastructure Management Services (iTIMS) [4]. This component is in charge of the devices network management through the concept of “surrogate” as a mediator mechanism in managing unique identifiers applied to the data base management [6] and later in devices abstraction with limited resources that are unable to manage state information or advanced features [7].

In addition to devices network management strategies in maintaining updated global state information, a key aspect is the establishment of open interfaces to minimize the need for adapters. In the electronic information exchange between heterogeneous systems has been a common practice the integration based on adapters. However, the costs and risks associated with the development of integrated systems, in particular by establishing technological dependencies (vendor lock-in solutions) suggests the development of strategies based on the definition of open interfaces.

In recent years the trend in the IoT area includes the development of open architectures aiming the systems integration in an organization and the definition of new models for the coordination of increasing complexity in the exchange of electronic messages between organizations. In the latter case, a significant work has been developed in the field of collaborative networks standing out works leading to the structure of organizational networks where is required that the companies progress towards a framework of preparation to cooperation through the implementation of what is known as a Virtual Breeding Environment (VBE) [8] in supporting the establishment of virtual organizations (VO) [9]. Thus, it was proposed a collaborative platform ECoNet aiming to structure the collaboration between organizations in the transports and logistics domains where the members of this network can share and exchange information using a common middleware infrastructure [10].

3 Proposed Approach Architecture

The definition of a communication open interface between devices and the host of the approach proposed in this paper, it is an opportunity for the projection of some of the above listed concerns. Thus, for the open interface definition, the following guidelines are considered:

  • Characterization of requirements and its generalization in an accountability framework formulation (capabilities) of a MSU unit:

  • Functional model: Data model; Exceptions; Tests/Compliance (conformance tests); Interface and semantics/coordination of access operations.

  • Monitoring model: Data model; Operational quality assessment rules.

  • Decoupling strategy of MSU units through surrogate services (MSU-S) being the development management responsibility of each unit as follows:

    • Coordination server of a set of surrogates through a gateway server (MSU-G): Responsible by communications with the network of MSUs.

    • Implementation strategy of each MSU-S: Pairs lifecycle (MSU, MSU-S); Pair monitoring (MSU, MSU-S), where a MSU-S may or may not reflect a MSU (based upon availability and status update rate of the status of these two systems (tandem).

    • Set of interfaces to be made available as open specifications and may evolve in the context of standardization processes.

As a first approximation, it will be considered the overall architecture of the proposed approach into its main components, Fig. 2. It will be considered an information system, generically called IT-System, with the responsibility of access one or more MSU networks.

Fig. 2.
figure 2

General system architecture of the proposed approach.

Full size image

A MSU network is established by a group of solidary MSUs with a particular process or set of transport processes. In the context of the current approach, the aim is focused on the validation of an interface or interfaces proposed as an open framework. This validation focuses on the MSU network management key component, itself an IT-System installed in containers or other mobile (nomadic) resources. This component, called MSU Technological Infrastructure Management Services (mTIMS) has the responsibility to provide access services to each of the distributed units (remote) MSU transparent to communication failures or periods when the units are turned off (for maintenance or other reason). The iTIMS is responsible for the management of groups of transponders associated to specific transport processes. It uses services implemented by the mTIMS it-system.

Thus, the architecture of the IT-System, mTIMS (Fig. 3), includes the following main modules:

Fig. 3.
figure 3

TIMS component architecture and its connection to MSU network.

Full size image
  1. i.

    Security and authentication mechanisms to access, either by users, or by other IT-Systems;

  2. ii.

    Monitoring the implementation and a model of cooperation with a monitoring infrastructure for maintenance management based on open specifications such as SNMP or JMX;

  3. iii.

    A manager of remote connections (MSU-G or MSU-gateway), sometimes with multiple access numbers (GSM/UMTS/LTE), with responsibility for management of communication channels (uplink/downlink) with the MSU units installed in containers or other mobile resources;

  4. iv.

    Set of MSU-sets (MSU-S) where a MSU-S object corresponds to a surrogate of a physical unit (MSU) forming a pair (tandem). A MSU-S instance extends the capabilities of a MSU including the possibility to respond to a service to obtain a location when it is not possible a connection with a unit (crossing a zone without GSM coverage).

The pairing type (tandem) between a physical unit with a unique identifier (UID-MSU) with its MSU-S-UID, which is associated with the same unique identifier, makes available an MSU with extended capabilities and this runs in a computing platform with potential unlimited resources (e.g., using cloud computing). The management of the life cycle of a MSU unit should ensure that the state of the surrogate unit is consistent with the physical unit, in particular, always an action occurs by a manual process. If the unit is shut down permanently (by a permanent fault) the respective MSU-S should also be eliminated, staying for the purposes of historical information the registration of the “slaughter” together with other information related to their working state.

For an enhanced management of MSU devices in different application contexts (different IT-Systems from different stakeholders) is introduced the concept of MSU groups. An IT-System can access more than a set of MSU devices.

3.1 The MSU-Surrogate (MSU-S) as Abstraction Module of the Device MSU

For each device (MSU) installed on some mobile resources (container, truck, wagon, etc.) there is an instance of a model that represents it (surrogate), Fig. 4. Essentially an MSU-S maintains updated information regarding an MSU, its equal (surrogate). Such an information update depends on the policy adopted for communication with an MSU, which is constraint by the energy consumption. Although the proposed approach has been designed having as key mission the autonomy of a unit through harvesting techniques, the energy should be managed as part of a policy of reducing consumption by which the number of communications between an MSU and the mTIMS system should be maintained in minimum.

Fig. 4.
figure 4

MSU-S unit (surrogate) architecture.

Full size image

Either because long periods without communication or because the unit is in a location without access to the communications network or yet because the unit is turned off (e.g. for maintenance), it is intended that an IT-System (client) can access the information of an MSU device. That is, it is the responsibility of the mTIMS system to maintain a MSU-S set equal to a MSU set, so that through a MSU-S a client could “see” the corresponding MSU in its approximate state by inference of attribute of values that may have been modified by a state change of the respective MSU. This approximate state may refer to the geo-position of the MSU device. That is, until there is a new communication of the respective MSU, the corresponding MSU-S can respond with an inferred position, by calculation or application of some heuristics as to give the position with a certain degree of confidence associated. An example could be an MSU device associated with a container moving between point A and B.

Knowing the last position, the azimuth (direction), the direction of movement, speed and geographic information/roads, a computational agent infers at each instant the position value with an associate degree of confidence. The architecture of a MSU-S module that virtualizes a MSU device, consists of the following key components:

  1. i.

    A sequence of states of a virtualized MSU device (MAX_STATES_QUEUE, maximum number of ills states, one for each access to an MSU device);

    An extended interface related to the interface of a device (MSU), i.e., an interface of a virtual device MSU-S, such that the computing capacity that is executed allows a set of functionalities difficult to implement in the corresponding device;

  2. ii.

    An evaluation module on the degree of trust of attributes of a MSU provided by its virtual view, when the values are not updated for more than a MSU_DeltaUpdate time, defined by configuration.

3.2 Open Interfaces of the Proposed Approach

In SoaML model, Fig. 5 depicts the main open interfaces to various levels of cooperation. The proposed approach considers a set of interfaces to be implemented for access by IT-Systems, either by the demo application of the current approach or other approaches. The open interfaces are as follows:

Fig. 5.
figure 5

Model SoaML of the services architecture.

Full size image

  • mTIMS Interface

    • Communication interfaces with mTIMS system to obtain the reference of a particular MSU-S, and later access through the operations provided by a MSU-G:

      • IMSU_S - access interface to a virtual representation of a MSU device;

      • IMSU_G - interface that allows obtain, upon client application authentication, an end point for a MSU_S that allows access to information of the respective MSU.

  • Uplink/Downlink (MSU) Interface

    • Access interface to a MSU, through its MSU-G (gateway) in the uplink operation;

    • Updating attributes interface of a MSU, through the respective MSU-G (gateway) in the downlink operation.

The interfaces considered a minimum set of functionalities. The objective of the proposed approach is the definition of a generic interface even without considering specific requirements arising from the evaluation of one or more application domains.

The messages exchanged between services (producers and consumers) have been described through messages models directly convertible to eXtensible Markup Language (XML) and based on the Scheme Definition (XSD) grammar.

The proposed models represent a first approach to an initial version of an open specification for the distributed computing responsibilities (the connected intelligent things). It is expected that more complete and robust models are proposed as validations identifies features that were not considered but important to the required completeness of critical operating solutions.

3.3 Characteristics of MSU Device

The developed autonomous locator is self-sufficient, with a rechargeable built-in “battery”, being the corresponding blocks diagram depicted in Fig. 6(a). It integrates GPS and GSM/GPRS technologies and other sensors such as accelerometer, temperature and real time clock. The locator, whose prototype is shown in Fig. 6(b) is intended for market of goods transport and further to harvest energy from the vibrations and the sun, which is one of the innovative aspects that presents itself to the sector. The locator will integrate the DSRC-MDR technology (radio technology used in the Via Verde toll identifiers) thus enabling the unit to detects tolls in all countries that use the radio frequency identification technology (5.8 GHz) TC270 DSRC-MDR. This information will be relevant for logistics operators or logistics parks because they allow accurately track cargo passage sites, without using GPS or GSM network. This potential collaboration involving highway concessionaires (as another collaborative stakeholder) has motivated the promotion of synergies with the ECoNet platform [10]. Nevertheless, the focus of the project is to develop the power generation system (“Energy Harvesting”) which will load the “battery” extending the unit life. This will prevent battery exchange after few months of use (when battery exchange is not possible, often results in the loss of devices).

Fig. 6.
figure 6

The MSU unit.

Full size image

To complement the system, it will be developed a “central system” with georeferenced maps for display the devices and all data sent by the remote units. The map chosen was the OpenStreetMap since it has a worldwide coverage and have not running costs. As far as other options are concerned, e.g. as the possible use of GoogleMaps, the choice of OpenStreetMap, beyond being made available in an open source model (Open Source), allows operation in offline mode. The current “central/back-office system” is presented in Fig. 7, where start/end and trip events, as well as, the electronic tolls detected with DSRC-MDR technology are shown. The unit under development has as main requirements the low cost and low energy consumption. Thus the computing platform chosen was a microcontroller with enough computing power to perform the various unit control functions but without the capability to support an operating system.

Fig. 7.
figure 7

A view of the monitoring web interface.

Full size image

To implement the GSM/GPRS communications was chosen the BG2-W module from Gemalto (former Siemens and former Cinterion) since it is a module with worldwide coverage (Quad-Band), small size, low cost and low power consumption.

Being available the GSM and GPRS technologies means that could be used the following communication approaches: SMS - communication limited to 160 characters to a mobile device; Data - communication via GPRS over the Internet. Of both types of communications should be privileged data communication due to low cost and ease of integration with the central computing platforms that integrate geo-referenced maps. However the SMS communication has the advantages of having a lower consumption due to reduced communication time. The GPRS communication has as main characteristic the fact of being billed by volume of data rather than the communication time. On the other hand, reducing the transmitted data minimizes the communication time and thus increases the device autonomy.

4 Conclusions

The architecture of the proposed approach bases its open framework on the possibility of allow multiple suppliers for an MSU device. For this to happen is necessary that the uplink/downlink messages between a MSU device and an IT-System gateway (MSU-G) be standardized, especially in the accuracy of the fields semantics that constitute the message. This would promote the participation in group or groups of standardization related to the field of transports or logistics so that the product that emerges from this project can gain international visibility and credibility.

The standardization of interfaces at the “back office” system level, the mTIMS system, assumes a dimension of industry promotion in terms of IT-Systems. In fact, the separation between the system (infrastructural IT-System) and the proposed system considered here concerned with the management application of a network of MSU devices, aims at a contribution to a system framework of open IT-Systems. We define a system of open systems (SoS), where one IT-System for which each subsystem has a market competitor. This is a complex challenge being that the mapping between requirements and capabilities of an IT-system is not of simple formulation, nor the establishment of a closed framework for standardization (full). In any case, the proposed approach aims to be an initial contribute in a validation of a modular framework contributing to an open SoS in a framework of development and operation management of transport, logistics, and other related processes.

The IMSU-TIMS interface in which we can consider as a more relevant interface the IMSU-S access interface to a virtual MSU device, would establish a standard framework for a manager of a network of MSU devices (potentially from different vendors). The architecture and interfaces proposed leave a set of open questions to be developed in specialized projects, concerned with a device perspective in their physical and functional characteristics, or in the perspective of the development of integrated systems for the management of transport processes. Such SoS, while being a complex distributed system have open challenges/questions unanswered as follows:

  • Definition of a reference model for component “Accuracy Confidence Agent” responsible for presenting a virtual interface of a MSU device, having the responsibility to reply with attribute values with a degree of confidence associated when the image of the physical MSU device is delayed by a given time;

  • The suggestion of the concept of MSU sets (groups) for a more efficient management of a MSU devices network (eventually involving multiple transport companies) requires a modeling work to be reflected in the proposed interfaces;

  • The transport processes may involve more than one company which configures the need to formalize a collaborative network where companies (organizations) with different cultures of organization/processes and technology have to coordinate their collaborative processes. These involve the infrastructure component (MSU) and the IT-Systems component responsible for coordinating the collaborative processes (exchange/sharing messages) and internal activities of the organization;

  • Model of integrated maintenance management through standardized monitoring interfaces that are able to be integrated with specialized IT-Systems of operation/maintenance management;

  • Integration of MSU devices with other embedded devices (on-board), e.g. integration of the tachograph system with a MSU in a container transported by the respective vehicle (tractor), requires the development of an open framework that enables interoperability between devices from different manufacturers where the interception of a set of functionalities is not null (potential redundancy, e.g., multiple GPS modules), or implement additional functionalities.