SMARTFREIGHT FACT SHEET TOPIC / ACTIVITY SMARTFREIGHT software development PURPOSE OF THIS TOPIC / OBJECTIVES OF THIS ACTIVITY IN SMARTFREIGHT •

Show important SMARTFREIGHT functions in a real-life demonstration.

•

Using vehicle-to-infrastructure (V2I) communication between the in-vehicle On-Board Equipment (OBE) and the Road Side Equipment (RSE).

•

Connecting the goods to the vehicle by using CALM MAIL/DSRC between the On-Goods Equipment and the OBE.

•

Showing two-way communication between the vehicle and the back offices of the Freight Distribution Management Centre (FDMC) and the Urban Traffic Management Centre (UTMC).

•

Using the CVIS service platform in a wider transport and logistics context.

WORK CARRIED OUT SO FAR / CURRENT STATUS The software development has been divided into three phases as shown in Figure 1 to the left: specification, implementation and demonstration. The software development process started early 2010 by working on the implementation specification and a plan for the implementation of the actual software. The specification phase has ended, while the implementation phase is on-going. This phase will continue until the demonstration in the SMARTFREIGHT final conference in Trondheim, October 13-14th 2010. Figure 1: Development phases

The specification is described in Delivery 3.1 “Implementation specification for new extended traffic management and freight distribution management functionality”, and is the responsibility of ETRA I+D. The motivation behind the implementation specification is to describe how the SMARTFREIGHT functions could be implemented. It is therefore a link between the SMARTFREIGHT architecture defined in Delivery 5.2, and the implemented software shown in the demonstration. The specification focuses mainly on the individual vehicle access control, resource booking and monitoring of goods functions, where they are described by means of processes and information models.

Figure 2: System components

The implementation phase involves the development of applications and services for deployment in both the vehicle (OBE and OGE) and the infrastructure (RSE, UTMC and FDMC). Figure 2 gives an illustration of the system components and how they are interconne interconnected. The fleet manager and traffic manager can communicate with the driver either through a RSE or long range communication like 3G. The Control Centre (CC) and Host Management Centre (HMC) are responsible for application provisioning and support. ftware development is built around a scenario that will be demonstrated in the The software SMARTFREIGHT final conference in Trondheim, October 13 13-14th 2010. In this scenario a driver will carry one type of goods with special requirements to temperature, before reloading reloadi with dangerous goods. Both types of goods will be carried in an urban environment that involves SMARTFREIGHT functions like access control and tunnel management. NEXT STEPS The actual implementations of the software started in April and will continue towards a full scale test in September 2010.. SINTEF and Q Q-Free are responsible for the implementation. The implementation will follow a distributed client-server server architecture as specified by CVIS, where the architecture components are thee OGE, OBE, RSE, and th the management centers FDMC and UTMC. The implementation of the system component software will happen in parallel to enable small scale testing of each application’s internal behavior and information exchange at different stages in the process. Milestones are defined for each application towards the full scale test and demonstration.

(PRELIMINARY) KEY RESULTS / CONCLUSIONS The main events in the SMARTFREIGHT demonstration represent important functions from the project. These events are: 1) access to the city, 2) monitoring of goods’ conditions, and 3) manage dangerous goods in tunnels. Each event has associated applications and services that realize the SMARTFREIGHT functions specified in D5.2 and D3.1. A short presentation of these applications is given below: Access control: A city Access and Priority Assignment policy (APA policy), describing requirements for controlled area entrance, is downloaded by approaching vehicles (triggered by service advertisements from a RSE). The policy is then compared to the vehicle properties (e.g. physical characteristics, type of engine, goods, etc.). The resulting Access and Priority Offers (APOs) give which areas the vehicle may enter, where the vehicle must report its presence, and how it optionally can buy accesses. All controlled areas will be shown to the driver through a map on the OBE. Goods monitoring: Goods will have transport requirements to e.g. handling and temperature. Sensors attached to the goods will provide the OGE with status information that is forwarded by the OGE to the OBE for notification to the driver or forwarded further to the FDMC. The OGE-OBE communication is handled by CALM MAIL/DSRC. Tunnel management: Tunnels are special cases of controlled areas that need access control. The tunnel management application uses dynamic measures and makes local access decisions in the RSEs guarding the tunnel’s entrances. In the demonstration, only one vehicle with dangerous goods is allowed into the tunnel at once. Any approaching vehicle carrying dangerous goods will then be told by the RSE to wait at a holding area in front of the tunnel. MORE INFORMATION Contact: Tor K. Moseng, SINTEF, phone: +47 (0)91 82 10 61, email: [email protected] Lola Alacreu, ETRA I+D, phone: +34 (0)96 313 40 82, e-mail: [email protected]