The control logic of each of the system's agents, most notably of each shuttle, is ... The Banking Agent is in charge of transferring money from and to the shuttles, ...
Autonomous Shuttle System Case Study ? Holger Giese and Florian Klein?? Software Engineering Group, University of Paderborn, Warburger Str. 100, D-33098 Paderborn, Germany
[hg|fklein]@upb.de
1
Introduction
At the University of Paderborn, the Railcab project is developing an intelligent railbased transportation system. Its vision is to combine flexible, on-demand scheduling with cost and resource effectiveness, thus offering the advantages of both individual and public transportation. Fleets of intelligent shuttles capable of transporting a small number of passengers or a single freight container autonomously navigate a passive track system and make independent and decentralized operational decisions. At the Dagstuhl Seminar Scenarios: Models, Transformations and Tools, a case study focussing on the logistic aspects of this system was used in an extra design session. As it is consequently referenced by several papers in these proceedings, we provide a short description of the case study in the following sections. After a short overview in Section 2, we describe the architecture of the provided simulator in Section 3 and finally outline the possible interaction scenarios in Section 4. For further information and a detailed interface specification, please consult the case study web site.1
2
System Overview
The case study is based on a very simple system model. Shuttle agents move around on a topology consisting of railway stations interconnected by track sections. Orders for transportation tasks that consist of moving a certain number of passengers from one station to another while respecting a certain deadline are published and auctioned off among the shuttles. The lowest bidder is awarded the task and paid upon successful completion, but risks a contractual penalty in case of tardiness. Shuttles need to pay for track usage and maintenance. The Network The railway network is modelled as a directed graph. Nodes may be stations or either converging or diverging switches. Stations can simultaneously accommodate an unlimited number of shuttles. Maintenance is carried out at stations, but only if explicitly initiated by the shuttle. ?
?? 1
This work was developed in the course of the Special Research Initiative 614 - Self-optimizing Concepts and Structures in Mechanical Engineering - University of Paderborn, and was published on its behalf and funded by the Deutsche Forschungsgemeinschaft. Supported by the International Graduate School of Dynamic Intelligent Systems. http://www.upb.de/cs/ag-schaefer/CaseStudies/ShuttleSystem/. There, you may also download a more detailed case study description and a simulation environment implementing the specification, which can serve as a testbed for shuttle designs.
The directed edges represent tracks that may only be traversed in the specified direction. Paths on the graph correspond to track sections. A track section that directly connects two stations is called a connection and needs to be unique. Connections may share common track sections, but it is currently not possible to deviate from a connection once the traversal has been started. They may be temporarily disrupted, which does not affect the shuttles currently travelling on it, but only keep new shuttles from entering it. All shuttles are duly informed about disruptions and may opt for an alternate route. Orders Orders are published and auctioned by a broker. They specify a starting point, a destination, the number of passengers, and the contractual penalty. Besides, they are stamped with their publication time, the time the auction ends and the deadline for the completion of the order. The deadline is computed by adding the predetermined processing time to the time when the order is accorded to the lowest-bidding shuttle at the end of the auction. Any shuttle may place bids for any order. In case of a tie, the shuttle that first made the offer is awarded the order. Shuttles Shuttles are responsible for processing and executing the orders. They have a fixed maximum capacity for transporting passengers. They may transport any number of orders at a time within the limits of their available capacity. There is no limitation on the number and total capacity of the orders a shuttle may bid for and obtain simultaneously. Shuttles complete orders by travelling to the starting point, explicitly picking up the passengers, proceeding to the destination and unloading. Passengers may not be unloaded anywhere but at their destination. Income and Expenses At initialization time, shuttles receive a fixed seed capital. A shuttle with a negative balance is bankrupt. It is retired at the next train station.During the run of the simulation, orders are a shuttle’s only source of income. Upon successful completion of an order, the shuttle needs to claim the payment. An order may specify one of two possible modes of payment: credit card payments are transfered immediately upon receipt of the claim, while invoiced payments may be deferred. A shuttle may need to send up to two reminders, each preceded by a waiting period of no less than 2500 simulation periods, before it is paid. All invoices are paid eventually. Premature reminders are ignored, however. Shuttles incur three different kinds of expenses:
– Toll: a fee for the utilization of connections is levied upon arrival at the destination. The amount is fixed and determined by the topology. – Maintenance: maintenance takes place at train stations and consumes both time and money. It is automatically triggered once the distance travelled since the last maintenance exceeds a certain limit, but may also be scheduled at any earlier time by the shuttle. It can not be interrupted, however. Payment is immediate. – Contractual penalties: if a shuttle does not complete an order before the associated deadline, it needs to pay the specified contractual penalty. It is still compelled to complete the order, but will receive no payment. If the shuttle has not even loaded the order before the deadline, it needs to pay the amount of its bid in addition to the penalty and loses the order.
3
Architecture
All interactions between the different agents in the system are realized using messages. The key aspect of the system’s architecture is therefore the approach to message passing. The control logic of each of the system’s agents, most notably of each shuttle, is run in a dedicated thread in order to ensure a fairer distribution of resources and keep individual agents from blocking one another. While Java method calls are by nature synchronous, a mechanism was devised to enable the simulation of asynchronous message passing by means of a message handler. It accepts message objects, relinquishes control of the sending thread immediately afterwards and then delivers the message at the appropriate time. As it is responsible for queuing, routing and delivering all internal and external messages, the message handler is the central entity of the system (see Figure 1).
Shuttle
TopologyAgent
MessageHandler
DisablingAgent
BankingAgent
Simulator
BrokerAgent
Event Log
XML Log
Fig. 1. Kernel components
All components of the system are derived from the Agent type. It provides the basic interfaces and data structures for interfacing with the communication framework. The kernel consists of five agents. – The Topology Agent stores and publishes the network’s topology – The Broker Agent loads or generates a sequence of orders, publishes them, and manages the auctioning process. The generated sequences of orders are logged to an XML file that may be used to reuse an identical scenario for testing and controlled experimentation. – The Banking Agent is in charge of transferring money from and to the shuttles, and the invoicing process – The Disabling Agent randomly disables connections between stations – The Simulator simulates the physical part of the system. Running inside the Simulator, there is a shuttle process representing the hardware component of each shuttle. Shuttles may communicate with their shuttle process using a special set of messages defined below. The Simulator keeps a debug log that can be used for the analysis of a simulation run. – The Shuttle Agents control the shuttles’ operation. They must be derived from the ShuttleAgent type and, for performance reasons, may not create additional threads nor read from or write to files.
4
Interaction Scenarios
A set of interaction scenarios between shuttles, their physical sensors and actuators and the agents of the system kernel exists. Shuttles can issue commands, e.g. to move to a station, or request information about the environment, e.g. whether a particular connection is currently interrupted. Though central to the architecture, the message handler is just repeating received messages and does not add anything to the interaction semantics from the application perspective. In order to increase their clarity, we will therefore omit the message handler from the descriptions and treat all exchanges like direct interactions. Nonetheless, a delay occurs whenever messages are passed to the message handler, which has to be considered when requesting wake-up calls or calculating internal deadlines. As most exchanges are fairly basic, we only provide a diagram to illustrate a more complex example in order to keep this document compact. As the message handler simulates asynchronous communication, the diagram uses the arrow shape expressing asynchronicity. Shuttle Commands All shuttle command messages follow a basic command and reply schema. The shuttle agent expresses its desire to perform a certain action, then the shuttle process gives the appropriate response. Commands include moving to a destination, loading and unloading tasks, initiating maintenance, etc. The shuttle process checks the associated requirements, e.g. in case of a move command whether source and destination are valid, no maintenance is due, and there is sufficient money to pay the toll. The shuttle process then replies with a message indicating whether a request was valid or invalid, and a second message once the command has been executed completely in the former case. Broker Agent Interaction The Broker Agent publishes Orders with the OrderAvailable message. Shuttles may then calculate their price and reply with a MakeOffer message. The broker then evaluates the offers and sends an AssignOrder message to the winner. The losing bidders are not informed about the result of the auction. Topology Agent Interaction The topology represents one of the most important features of the shuttles’ environment. During initialization, shuttles request this information from the Topology Agent, which returns a collection of TopologyDataObjects. Additionally, the agent sends a GameConstantsMessage containing the simulation’s parameters. Banking Agent Interaction The Banking Agent is in charge of all financial transactions. It is the recipient of claims and reminders, and checks their validity and timeliness. It transfers payments to the shuttles’ accounts, but is also responsible for deducing tolls, penalties, and maintenance cost. Auxiliary Messages There are four classes of auxiliary messages. The first type allows the shuttle to enquire about the state of the environment, e.g. the current simulation time, its own position and account balance, or disabled track sections. Secondly, a shuttle may send messages to the visualization component, usually containing some implementation-specific details to display. Then, there is the possibility to request a wake-up call from the simulator at a certain time or when a certain event occurs, and
send the shuttle thread to sleep in order to save processing resources. A shuttle will equally be activated whenever any other message is sent to it. Exemplary Interaction The diagram below (see Figure 2) shows a typical sequence of interactions between a shuttle and various kernel agents. A shuttle bids for, obtains and successfully completes an order.
BrokerAgent
shuttle:ShuttleAgent
Simulator
BankingAgent
1: OrderAvailable - Order A 2: Calculate Offer
3: MakeOffer - Order A
4: WakeUpRequest sleeping
5: OrderAvailable - Order B 6: Calculate Offer
7: WakeUpRequest 8: Calculate Offers - Order A
sleeping
9: Assign Order - Order A 10: Calculate Offers - Order B 11: Calculate Path
(11 - 15) This block is repeated until start station is reached
12: MoveShuttle 13: Check Command 14: ShuttleMoving 15: ShuttleArrived 16: LoadShuttle - Order A 17: Check Command
Like steps (11 - 15) until destination is reached
18: ShuttleLoaded - Order A 19: UnloadShuttle - Order A 20: Check Command 21: ShuttleUnloaded - Order A
22: Invoice - Order A
Fig. 2. Exemplary interaction scenario
