=Paper=
{{Paper
|id=Vol-1360/paper8
|storemode=property
|title=Challenging Service Extensions for Electric Vehicles in Massively Heterogenic System Landscapes
|pdfUrl=https://ceur-ws.org/Vol-1360/paper8.pdf
|volume=Vol-1360
|dblpUrl=https://dblp.org/rec/conf/zeus/ApelPS15
}}
==Challenging Service Extensions for Electric Vehicles in Massively Heterogenic System Landscapes==
https://ceur-ws.org/Vol-1360/paper8.pdf
Challenging Service Extensions for Electric
Vehicles in Massively Heterogenic System
Landscapes
Sebastian Apel, Thomas M. Prinz, and Volkmar Schau
Department of Computer Science
Friedrich-Schiller-University Jena
Jena, Germany
{sebastian.apel, thomas.prinz, volkmar.schau}@uni-jena.de
Abstract The national goal of the federal government of Germany is to
have one million fully electric vehicles in use until year 2020. Since an
average tour of vehicles in inner-city logistic is about 80km, it is promising
that such logistic companies use electric vehicles for their tours. However,
there are some reasons for doubts in companies: unknown behaviors,
inaccurate range forecasts, and high costs.
The research project Smart City Logistik will provide a service to optimize,
monitor, and analyze electric vehicles in logistic scenarios for abolishing
those barriers. There, the integration of a service system in existing IT-
solutions by using predefined interfaces is challenging. This service system
needs special implementations for each company solution, what could
be avoided by using a more standardized way in logistic softwares. The
overhead can be reduced by a harmonized terminology in combination with
a standardized service bus to enable specific internal service extensions
in existing logistic solutions.
Keywords: Reference architecture, electric vehicles, logistic, interface, transport
management system
1 Introduction
To enable inner-city logistics with electric vehicles, the German Federal Ministry
for Economic Affairs and Energy (BMWi) has started, amongst others, the
collaborative research project Smart City Logistik (SCL). The project combines
an intelligent tour planning system with dynamic range prediction, based on
detailed knowledge of major influencing factors. The SCL service system is able
to support dispatchers and drivers with real-time feedback, by optimizing the
driving style, and by providing alternatives for a successful end of planned tours.
That SCL system should extend existing IT-solutions by using their data and
by offering standardized interfaces for service requests rather than substitute
them. However, the use case of proceeding external data about orders, customers,
T. S. Heinze, T. M. Prinz (Eds.): Services and their Composition, 7th Central European Workshop,
ZEUS 2015, Jena, Germany, 19-20 February 2015, Proceedings – published at http://ceur-ws.org
Challenging Service Extensions for Electric Vehicles 45
drivers, and fleets to calculate optimized and energy efficient tours is not common
– but in case of increasingly rapid innovation cycles more necessary.
As part of the project, SCL develops a reference architectural design for data
exchanges between independent service systems in logistical scenarios based on
a harmonized terminology. This design will describe how to enable or extend
an existing IT-solution to provide data, how to receive them by newly created
services, and how to embed the results back to existing IT-solutions. Furthermore,
this design describes how to provide these results for other, more specific services.
To achieve this goal, the paper starts with an explanation about the software
landscape in logistic IT-solutions, how they are clustered and how they are
used in companies (Section 2). Followed by that, there are multiple use cases as
examples in which these state-of-the-art solutions will lead to problems (Section 3).
Afterwards, a first draft for a reference architecture for service-based extensions
in existing IT-solutions is derived in Sect. 4. Eventually, the paper considers
related work (Section 5) and concludes with a short outlook into future work
(Section 6).
2 Software Landscape in Logistic Companies
Enterprise resource planning (ERP) describes a wide range of tasks handled
by companies to manage their resourcese. g., financial accounting, data services,
manufacturing, and human resources, as well as customer relationship manage-
ment and supply chain management (SCM). One focus of companies with logistic
background is the SCM while ignoring human resources and financial accounting
at this point. This part of ERP describes a whole range of mechanisms and
theories for supply chains. In detail, these chains start with acquisition, followed
by production and distribution, and are finalized by sales [2]. SCM covers the
whole production process and the logistic to handle these workflows. As a part
of this, there are system solutions (transport management system (TMS) and
warehouse management system (WMS)) to cover special parts of the SCM. These
TMS and WMS handle requirements found in inner-city logistic scenarios like
package, food, drug, and express delivery, as well as services, e.g., automate
maintenance and restocking. A TMS covers functionalities about fleet, employee,
order, and billing management. Furthermore, it contains tour and route calcula-
tion, tracking, statistics, and dispatching. A WMS on the other hand handles
management of warehouses, positions, and amounts of stored articles, and helps
to manage dispatching centers.
These functionalities of TMS and WMS will be combined to get a solution
for each company to cover their needs. A closer look at these solutions will show
a number of more then 50 different tools [1, 5]. Each tool has an unique set of
interfaces and has more or less of the before described elements of TMS and WMS
theories. Such interfaces mostly covers common DATEV and financial accounting
interfaces, along with less interfaces based on electronic data interchange (EDI)
standards1 or proprietary REST, SOAP or COM solutions [5]. These interfaces
1
A standardized set of document descriptions for data exchanges.
46 Sebastian Apel, Thomas M. Prinz, and Volkmar Schau
Figure 1. Abstracted service architecture based on the Model-View-Controller pattern.
are mostly designed to interact with other companies to realize transportation
chains and managing orders.
An abstract Model-View-Controller based service to communicate with a
TMS/WMS is illustrated in Fig. 1. This service shows an interaction with external
datasources (like weather, traffic, and electricity rates information) on the left
hand side, which is mostly unproblematic because of their public availability. The
interaction with a TMS/WMS as illustrated on the right hand side is challenging,
but necessary to enable ideas as described before.
3 Use-Cases for Services
In case of logistic, there is a wide range of innovations e. g., by using electric
or hybrid vehicles. Those innovations could lead to required new services. Such
services must be used to enable the innovations in existing environments. However,
the current landscape in software solutions for logistic companies does not allow
for their easy embedding as mentioned before. There are several use-cases for
such services currently considered in research projects.
The first example is the optimization of energy consumptions and costs by
using electrical cars in company fleets as energy buffer2 . These buffers are used,
when the provider’s energy price is above a predefined threshold. To enable such
solutions, the company needs an energy management system deciding which
source of energy is used. In case of prices greater than the threshold, buffered
energy can be consumed. In case of prices lower than this threshold, provider
energy can be used. In case of a planned tour for a specific vehicle, that energy
management system must ensure, that the vehicle is prepared in time. To realize
such a management system, the service needs to know when vehicles have to start
tours. For example, by using a read access to vehicle time sheets and planned
tours from an existing TMS/WMS solution.
2
iZeus Smart Grid www.izeus.de
Challenging Service Extensions for Electric Vehicles 47
Another example is the management of charge scheduling3 . A lot of current
installed energy systems are not suitable to handle the full amount of required
power in case of simultaneous fleet charging. As a result of this, it is necessary
to schedule the charging processes to avoid network peeks. Again, this could
be done by using a special management system which decides, which vehicle is
allowed for recharging now. Using a read access for vehicle time sheets and fleet
information in existing IT-systems would enable such decisions.
A third example is an optimized routing algorithm for electric vehicles as
suggested in the SCL project4 . Currently, combustion engine based vehicles can
refill their fuel when necessary. Because of missing charging infrastructure and a
high amount of time to charge, this is not suitable for electric vehicles. To avoid
stranded vehicles, a forecasting system should be used to plan energy-aware tours.
Such a system could be used as extension by using data about vehicles, drivers
and orders from a TMS/WMS. That extension would work as an external service
with read access for required data. Additionally, this solution could push back
the results to the TMS/WMS service, which requires an additional write access
for tour data.
The examples illustrate situations in which an extension of TMS/WMS is
necessary. In practice, this requires an individual extension in each system instance,
developed by the original author of the applied solution. As an alternative, an
external service can be based on available interfaces. In this case, there would be
no standardized communication, the service has to use available REST, SOAP
and COM interfaces and provide an individual implementation to access the
data. Furthermore, this means an individual interface implementation in each
TMS/WMS solution for each example.
4 Towards a Reference Architecture for Logistic Service
Communications
A reference architecture is profitable for the integration of new services especially
to reduce complexity in data exchanges. Such an architecture may define a
communication structure to request internal process data between different
services and to inform about state changes. We have derived those parts of the
architecture in several steps for our own first approach:
The first step was to analyze business processes in inner-city logistic companies.
Analyses were done by interviewing actors in inner-city logistic companiese. g.,
dispatchers and drivers, about their everyday work. Questions comprise among
others for example: Which tools and software are used? Which workflows will be
handled and which exceptions could occur?
The result of those interviews are business processes about tour planning,
handling orders, managing picking, packing and delivery, and the knowledge
about used software and tools.
3
Econnect Duisburg www.econnect-germany.de, enviaM in sMobility www.smobility.
net, and SAP in iZeus
4
SmartCityLogistik www.smartcitylogistic.de, and PTV Group in iZeus
48 Sebastian Apel, Thomas M. Prinz, and Volkmar Schau
Figure 2. Example of a bus architecture in case of extending a existing TMS/WMS.
An optional adapter could be implemented as a proxy in case of missing support.
The analyses about the IT landscape in logistic companies and the interview
results were used to create a knowledge base about entities and their relationships
in the second step. This knowledge base is context dependente. g., the under-
standing of a tour can differ in international logistic and inner-city logistic. In
our case, the context is based on inner-city logistic. This base leads, by using a
suitable modeling method, to a well-controlled vocabulary, which will be used
as a base for a data description language (DDL). In case of the SCL project the
SCL-DDL covers all terminologies based on their well-structured entities and
their relationships.
We got a loosely coupled set of services and funtions with individual de-
pendencies and communciation flows in the third step by using the following
ideas: (1) A single IT solution in a logistic company is a subset of functions
described in TMS and WMS theory with internal dependencies. (2) Additional
functions (services) enable new innovations by using dependencies to internal data
represented by functions of TMS and WMS. (3) The union of all functions and
services of steps (1) and (2) builds a loosely coupled IT solution for logistic with
individual dependencies and communication flows. A communication bus can be
used to handle such a set of functions: Large companies use a communication bus,
see enterprise service bus (ESB), for arranging a large set of interacting systems.
Vehicles uses bus based systems to manage their vehicle systems (see CAN-BUS).
By using a domain specific DDL and a standardized communication protocol,
the bus can be used to interact between different services and functions.
A TMS/WMS solution could implement the bus feature and an additional
service to handle the communication between services. In case of TMS/WMS
solutions which do not implement the bus, an adapter may connect a subset of
their available interfaces to the bus. However, a single service system must not be
specialized to interact with one IT-solution. A single service system only needs
an implementation for interactions with the standardized ESB infrastructure.
Figure 2 shows how to use that bus in combination with the previously described
use cases.
Challenging Service Extensions for Electric Vehicles 49
5 Related Work
Several approaches improve the modeling of logistic based architectures or specify
the content and meaning of communications between companies. Often, such
approaches describe single systems, architectures, or object models to manage
situations within a single company instance [3, 4, 6, 7]. The integration of new
services would lead to specific extentions.
In the case of standards, RosettaNet and UN/EDIFACT should be mentioned.
RosettaNet offers a wide range of specific language, business objects and business
processes [8]. United Nations Electronic Data Interchange For Administration,
Commerce and Transport (UN/EDIFACT) is one of several international EDI
standards. UN/EDIFACT offers a list of specifications for the description of a
wide range of documents for e-commerce. This includes documents about routing
instructions, orders, purchases, shipments, and billing for example. However,
those documents describe data interchanges between companies, but not how to
transport them.
6 Conclusion and Outlook
Electric vehicles in inner-city logistic scenarios could be a perfect synergy. Such
vehicles are nearly soundless, may have zero emissions, and could help managing
the raising number of freight transports without lowering living qualities in
urbane areas. Because of range restrictions, missing e-specific infrastructures and
long recharging rates, there is a need to handle those restrictions by supporting
planning and monitoring processes.
The SCL project manages a system for optimization of plans, monitors, and
analyses of tours for electric vehicles. The integration of that system in existent
environments is currently an individual implementation which has to be done for
each system. Alternatively, the logistic companies may wait for an integration
by the producer of their systems, which leads to large delays or high costs in
enabling new innovations.
The efforts in reaching one million electrical cars in 2020 leads to a wide range
of different e-specific researching projects to help to provide solutions to enable
them. Especially in case of inner-logistic it is possible to manage the restrictions
of these cars. Unfortunately high acquisition costs and low profit margins will
slow down the innovation processes. Reducing complexity and defining more
common standards for internal process data in logistic IT-solutions could help to
overcome this situation.
References
1. Busch, A., Dangelmair, W., Pape, U., Rüther, M.: Marktspiegel Supply Chain
Management Systeme. Gabler, Wiesbaden (2003)
2. Chopra, S., Meindl, P.: Supply Chain Management, vol. 3. Pearson Education, New
Jersey (2007)
50 Sebastian Apel, Thomas M. Prinz, and Volkmar Schau
3. C.Quiroga, N.Koncz, E.Kraus, J.Villa, J.Warner, Y.Li, D.Winterich: Guidance for
developing a freight transportation data architecture. NCFRP Report 9 (2011)
4. Dürr, E., Giannopoulos, G., Brugge, R.: Towards an european intermodal freight ar-
chitecture, ftp://ftp.cordis.europa.eu/pub/telematics/docs/tap_transport/
thessalonikivs4.pdf
5. Die Qual der Wahl. Logistik Heute pp. 36–37 (May 2005)
6. Moore, M., Kumara, S., Richbourg, R.: An architecture for logistics replanning.
Expert Systems with Applications 11(2), 177–190 (1996)
7. Re, S.D., Campagna, A., Nanni, U.: A reference architecture for freight
transport manangement systems, http://freightwise.tec-hh.net/
A-reference-architecture-for-freight-transport-management-systems.pdf
8. RosettaNet: Overview - Clusters, Segments, and PIPs (February 2003)