arX

iv:2

104.

0530

5v1

[cs

.MA

] 1

2 A

pr 2

021

A Hierarchical State-Machine-Based Framework for Platoon

Manoeuvre Descriptions

Corvin Deboeser1, Jordan Ivanchev1,2, Thomas Braud1, Alois Knoll2,4, David Eckhoff1,2, and

Alberto Sangiovanni-Vincentelli3

1TUMCREATE, Singapore2Technical University Munich, Germany

3University of California, Berkeley4Nanyang Technological University, Singapore

April 13, 2021

Abstract

This paper introduces the SEAD framework that sim-plifies the process of designing and describing au-tonomous vehicle platooning manoeuvres. Although alarge body of research has been formulating platoon-ing manoeuvres, it is still challenging to design, de-scribe, read, and understand them. This difficultylargely arises from missing formalisation. To fill thisgap, we analysed existing ways of describing manoeu-vres, derived the causes of difficulty, and designed aframework that simplifies the manoeuvre design pro-cess. Alongside, a Manoeuvre Design Language wasdeveloped to structurally describe manoeuvres in amachine-readable format. Unlike state-of-the-art ma-noeuvre descriptions that require one state machinefor every participating vehicle, the SEAD frameworkallows describing any manoeuvre from the single per-spective of the platoon leader. We hope that theSEAD framework will pave the way for further re-search in the area of new manoeuvre design and opti-misation by largely simplifying and unifying platoon-ing manoeuvre representation.

1 Introduction

Multiple challenges must be solved along the way to aglobally optimised and highly automated urban trafficsystem. While the past has seen a large body of re-search and technological innovation on AV, platooningas a concept is still in its early stages. With the capa-bilities of vehicular awareness and communication inplace, research can now start building elaborate pla-tooning strategies to leverage on those technologicaladvancements.

A specialised body of research is concerned with for-mulation of collaborative driving manoeuvres whereasresearch is split into two major categories. The firstcategory optimises driving behaviour on the vehicle’s

dynamics level for smooth and energy-efficient driving.The second category, in contrast, centres around col-laboration and communication strategies, for instance,how an additional vehicle joins an existing platoon.Within the second category, researchers have inves-tigated specific cases of collaborative driving in pla-toons. Most papers focus on the specific details of onemanoeuvre and optimise it to a great extent in termsof stability (the trait of a manoeuvre not to lead todangerous traffic situations) or execution time.

Although most papers draw on the description ofmanoeuvres through finite state machines, there is noconsensus or convention among researchers how to rep-resent manoeuvres. This heterogeneity aggravates thecomparison of manoeuvres and requires researches toconstantly adapt to new conventions. Besides, the de-scription of manoeuvres through mere state machinesrequires multiple synchronised yet independent statemachines, one for each participating vehicle. Design-ing and reading these state machines can become chal-lenging even for simple manoeuvres. The objective ofthis work is to provide a framework that simplifies andformalises this description.

The proposed framework follows four principles:Standardisation, Encapsulation, Abstraction, and De-coupling (SEAD). Standardisation ensures a commonterminology among all areas within the frameworkand all researchers applying it. To take advantageof the repetitive occurrence of action-sequences invarious contexts, the Encapsulation principle allowsgrouping such repetitive patterns into re-usable mod-ules. Since some patterns may contain sub-patterns,the Abstraction principle leads to recursive encapsu-lation which allows considering manoeuvres and theirbuilding blocks on different levels of detail. The De-coupling principle, finally, separates the control of themanoeuvre from its execution. This allows describingmanoeuvres exclusively from the control-perspectiveof the platoon leader while the framework ensures thecorrect execution behaviour. The SEAD framework

1

may serve future research as a point of reference andtool to facilitate further manoeuvre investigations.

In summary, the contributions of this article are:

• We survey and structure the complex landscapeof AV manoeuvre research, identify shortcomings,and derive requirements for a new framework.

• We present SEAD, a novel AV manoeuvre frame-work to significantly simplify the process of ma-noeuvre modelling.

• We make a library of manoeuvres publicly avail-able, in both human-readable and machine-readable formats.

The remainder of this article is organised as follows:First we give an extensive summary of related workin the domain of AV manoeuvre modeling (Section 2).From this we derive in Section 3 requirements andprinciples that a common framework should fulfil andfollow. Section 4.4.1 introduces our new SEAD frame-work. Finally, in Section 5 we discuss possible exten-sions and conclude the article.

2 Related Work

The concept of an Autonomous Highway Systems(AHS) was first introduced by Varaiya in 1993 un-der the name Intelligent Vehicle/Highway System(IVHS) [1], promising increases in safety and inhighway capacity without the need of building newroads. These advantages emerge from two conceptualchanges as compared to a conventional highway: 1)the application of vehicle platooning and 2) a globaloptimisation of traffic flow and travel times througha layered control structure.

A platoon is composed of a leader and at least onefollower whereas, in most publications, the leader isthe first vehicle in the upstream direction. The ma-jor impact of platooning for an increased highway ca-pacity is the decreased inter-vehicle distance withinplatoons (intra-platoon distance d) as compared tothe inter-vehicle distance outside of platoons (inter-platoon distance D) [1]. As shown in [1], platooningmay increase road capacity by up to a factor of three.

In the platooning logic, the leader sets the platoonspeed and coordinates the manoeuvres performed bythe platoon, for example splitting a platoon into twoplatoons (Split manoeuvre) or merging two platoonsinto one (Merge manoeuvre). The followers followthe preceding vehicle according to their CooperativeAdaptive Cruise Control (CACC) system and reactupon commands issued by their platoon leader.

Although platooning itself increases road capacityand vehicle throughput, it may become more effectivewhen applying additional higher-order strategies thatleverage on the vehicle’s communication capabilities.The interconnection of vehicles and infrastructure al-lows to control optimal platoon forming, driving, and

splitting strategies and to optimise traffic globally in-stead of locally. The combination of such systemsyields an AHS. Due to its complexity, the structureof the AHS is split into five hierarchical layers [1, 2].Each layer fulfils a mutually exclusive task as shownin Figure 1.

Figure 1: Control hierarchies of the platooning controlsystem (summarized from [1–3])

At the highest level of the hierarchy, the NetworkLayer is responsible for optimizing the overall traveltime of all vehicles and the traffic flow in the entire net-work [2]. It is aware of all autonomous vehicles in theroad network and the current and predictable trafficsituation on every road [1,2]. To optimize travel timeand traffic flow, it balances the traffic load on eachroad by determining the ideal path for each vehiclethat travels from a defined origin to a defined desti-nation [1, 4]. For the case of IVHS, the network onlyconsists of the highway. The Link Layer is more de-centralized and implemented by a controller for eachroad segment [1]. The controller ensures a smoothtraffic flow on its road segment by distributing thetraffic vehicles among lanes [2]. Besides determininga dedicated lane for each vehicle or platoon, it also de-termines the target size and velocity for platoons onthat section [3]. For an IVHS, the road segmentationis realized by dividing the highway into segments ofequal length. These two layers are implemented in theinfrastructure and part of the roadside system. Thelayers below belong to the vehicle system, meaningthat every vehicle is equipped with modules to realizethe tasks of the three layers described below.

At the highest hierarchical level of the vehi-cle system is the Platoon Layer or Planning andCoordination-Layer. As a free vehicle, this layer de-termines actions to fulfil the path and lane directivesimposed by the layers above [3]. Part of this task isto determine lane changes, if a vehicle should join orleave a platoon [2]. As a platoon leader, this layercoordinates the actions with vehicles that are associ-ated with the platoon either as followers or potentialjoiners [1]. As a platoon follower, the platoon layercollaboratively performs action protocols which areinitiated by the platoon leader [1, 3].

The Regulation Layer and the Physical Layer areresponsible for realising the trajectories computed by

2

the hierarchically higher layers. Control loops in theRegulation Layer compute actionable commands forthe actuators and minimise the errors reported by thesensors in the Physical Layer [3].

The Platooning Layer, which is the focus of thispublication, contains collaborative driving logic: Pla-toons must be formed, maintained, and modified. Col-laborative driving of multiple vehicles is described bymanoeuvres. Manoeuvres encompass the driving andcommunication behaviour for all participating vehi-cles in the form of manoeuvre protocols. As shownin the subsequent sections, the description of manoeu-vres is complex even for simple ones. Our work, thus,aims to increase the comprehensibility and facilitatethe easy formulation of platoon manoeuvres.

A common way of describing these manoeuvre-protocols are communicating finite state machinese.g. [5–7]. In order to gain a better understand-ing of different manoeuvre description approacheswe present a simplified example of the JOIN TAIL-manoeuvre from [3] shown in Figure 2. The JOINTAIL-protocol describes the process of a free vehi-cle joining an existing platoon at its tail through twoCFSM.

Figure 2: Example description of the JoinTail proto-col as communicating FSM (simplification of protocolfrom [3]). (a) behaviour of the joining vehicle, (b) be-haviour of the platoon leader. Rectangles constitutethe states and the arrows the transitions. States withdouble-stroke are Idle States (i.e. starting and end-ing states of a protocol) and the ones with a singlestroke are action states (i.e. states where an action isperformed).

When a vehicle (Vehicle A) decides to join a pla-toon, it sends a join request to the leader (Vehicle B)of the platoon (Transition 1, T1). B either rejects(T2) or acknowledges (T3) the request. In the caseof rejection, both vehicles return to idle and the pro-tocol terminates. If the request is acknowledged, Awill wait for B to join the platoon. A moves to thetail of the platoon. Once arrived at the tail, A at-taches to the platoon, starts following the precedingvehicle (i.e. switch into CACC mode), sends a mes-sage to B that the join is completed (T4), and transi-tions into the follower-Idle State. Upon receipt of thejoin-completion message, B updates the platoon infor-mation and returns to idle. The protocol execution iscomplete and terminates.

This description shows that state machines synchro-nise through messages that are sent between the ve-

hicles. Since both vehicles operate through the sameset of protocols, they can expect the other vehicle tobehave synchronously.

The representation in Figure 2 describes the be-haviour as two separate FSM, each describing the pro-tocol for one role within the manoeuvre. FSM (a)shows the transition of a vehicle from one Idle Stateinto another. After extending the state machine bythe transition from a free vehicle into a platoon leaderthrough platoon formation, the entire behaviour couldbe explained in one role-agnostic FSM. This FSM op-erates on both vehicles independently and simultane-ously. Both participating vehicles then operate fol-lowing the same FSM schema, yet they are in differ-ent states during the manoeuvre and follow differentpaths through the FSM.

This approach was shown by [5] and is illustrated inFigure 3 as an extension to the example in Figure 2.The dashed arrows were added to combine the twoFSM into one.

Figure 3: Combined FSM that represents the JoinTail-protocol as shown in Figure 9. The dashed arrowsestablish the connection between the two state ma-chines.

In the same manner as in Figure 3, it is possible todescribe the entire behaviour of vehicles in one role-and manoeuvre-agnostic FSM, meaning that one FSMwould describe the entire platooning behaviour of avehicle for all roles.

Although FSM are the dominant way to describemanoeuvres in the current state of literature, re-searchers also applied other ways of illustration. Theauthors of [3] describe a manoeuvre in a role-agnosticprocess flow-chart. From this chart, they deduct role-specific state machines that are ultimately formulatedin the COSPAN (coordination-specification-analysis)system. COSPAN formalises CFSM to prove certainmathematical state machine properties such as com-pleteness or reachability [8].

In [9], the logical flow of manoeuvres is also de-scribed as a role-agnostic flow-chart. Focusing on V2Vcommunication, however, this paper also provides ad-ditional information flow-charts to describe the com-munication between the participating vehicles. In ad-dition to illustrations, the majority of papers describesthe logical flow of events in manoeuvres through tex-tual descriptions e.g. [3, 5, 7].

As mentioned above, most publications describemanoeuvres as FSM whereas only a minority appliesother visualization and description principles. How-ever, although most manoeuvre descriptions use the

3

same methodologies, there is still a vast heterogene-ity among all existing publications. Two dominantsources of this heterogeneity are: 1) different levels ofdetail, and 2) verbally differing descriptions to repre-sent identical actions.

Different levels of detail: Some manoeuvre de-scriptions show a level of detail that reaches the regula-tion layer with states such as Accelerate to Merge [3]or Set Speed to 30 m/s [5]. Other descriptions, orsometimes even the same description, stay on a veryhigh level within the platooning layer with states suchas Car Splits [7] or Move To Position [10]. Due tothese differences of abstraction level, FSM that po-tentially describe the same behaviour are, in fact, sig-nificantly different.

Differing verbal descriptions: Even if illustra-tions describe a manoeuvre on similar levels of detail,they may use different terminologies or different levelsof verbal abstraction for the same action. For exam-ple, the Join Tail-protocol was described in [10] andin [3] in similar logical ways. In both descriptionsfor the joining vehicle, a dedicated state equalises thespeed of the platoon and the joining vehicle by decel-erating or accelerating. While [10] describes this asSet Speed to 30 m/s and Catch-up and merge the pla-toon from the back, [3] expresses the same process asAccelerate to Merge. This poses a challenge when for-malising and comparing manoeuvres across differentpublications.

Besides these heterogeneities, we identified twoadditional factors that pose challenges when for-mulating manoeuvres. First, repetitiveness intro-duces pseudo-complexity, especially for those descrip-tions with high levels of conceptual detail. For in-stance, the process for a vehicle moving to a cer-tain position requires both communication and phys-ical action. The leader orders the joining vehicle tomove to a defined position. When at that position,the joining vehicle informs the leader about the ar-rival. These action-communication-patterns may oc-cur repetitively within a manoeuvre FSM.

Second, since manoeuvres are mostly performed bytwo or more vehicles collaboratively, the behaviourfor every participant is described in dedicated, role-dependent FSM. Reading these coupled state ma-chines requires a substantial effort as the reader mustmanually synchronize the state machines to under-stand the collaborative process.

Another very important aspect of platooning is com-munication. The Join Tail-protocol description in Fig-ure 3 shows the necessity for message transfers be-tween participating vehicles. V2V standards, how-ever, serve only collaborative awareness and are notsufficient for this case of collaborative driving. Re-searchers have developed various ways of formalisingthis communication while complying with the existingstandards. The authors of [31] propose two protocols:A Minimal Protocol and a Full Platooning Protocol.While the Full Platooning Protocol is equipped for se-cured two-way communication, the Minimal Protocol

is only suitable for one-way messages.The Minimal Protocol can be used for collaborative

awareness as well as manual platooning, meaning thata driver must manually initiate the joining or leavingof a platoon. Within the platooning protocol, theauthors differentiate among three types of messages:Service Announcements, Service Requests, and Con-trol Data Messages. Service announcements are sentby platoon leaders to advertise services, for instance,the availability to add another vehicle to the platoon.Service requests are, for instance, sent by free vehiclesto platoon leaders to express the willingness to join.Control Data Messages are sent periodically by pla-tooning vehicles to maintain and update the integrityof the platoon.

In [5], the WAVE Short Message Protocol(WSMP) [32] is applied to carry information on theCCH. The messages are of two types. The first typeare beacons. These beacons, like CAM, carry informa-tion about the vehicle state, e.g. the position, acceler-ation, and lane. Additionally, the beacon carries theplatoon ID and the current vehicle position in the pla-toon if the vehicle is platooning. The position startswith 0 at the platoon leader and increments with eachvehicle in the platoon counting upstream. The sec-ond type is micro-commands. These are used to initi-ate and control platoon manoeuvres. While beaconsare usually broadcasted, most micro-command mes-sages are unicasted or, if the manoeuvre involves mul-tiple vehicles, multicasted. The authors provide a setof seventeen micro-commands to enable a multitudeof manoeuvres. To give the reader a more completeoverview Table 1 summarizes the research efforts in-volving studying platoon manoeuvres that were con-sidered for this paper.

3 Requirements and Principles

To relief the shortcomings described in the previ-ous section, namely the challenges with comprehen-sibility, compilation and comparison of manoeuvre-descriptions, we propose a framework for the universaldescription of manoeuvres that builds on the four prin-ciples of Standardisation, Encapsulation, Abstraction,and Decoupling (SEAD). This framework will enableresearchers and engineers to easily define new or al-ternative manoeuvres within the platooning layer Fig-ure 1. First we will derive requirements for the frame-work design from the identified limitations, then wewill define goals that the framework should fulfil, andpostulate the overarching design principles to achievethe design goals. Figure 4 provides an overview of theinterrelations among deficits, goals, and principles.

The SEAD design framework aims to resolve themajor shortcomings that state-of-the-art manoeuvredescriptions face. The subsequent list summarises theidentified deficits and defines the scope of problemsthe proposed framework should solve.

• Varying conceptual depth: Varying levels of con-

4

Table 1: Research publications regarding platooning manoeuvres

Reference Manoeuvres Additional Information Cat*

Lu & Hedrick 2003 [11],Lu et al. 2004 [12]

Merge Design of controller for longitudinal merging, virtual platoon to pre-compute trajectory before manoeuvre P

Nowakowski et al. 2016 [13] Merge, SplitPlatooning for non-autonomous trucks with CACC technology

and V2V communication, manoeuvres performed by driversP

Segata et al. 2014 [10] JoinMiddle (FSM)Designing and investigating the JoinMiddle manoeuvre with

various interference scenarios and communication packet lossP

Hsu & Liu 2004 [14] LaneChange Proposes manoeuvre to LaneChangeAndFollow for higher efficiency P, RHsu & Liu 2008 [15] LaneChange Investigates LaneChange options: simultaneously and time delay with varying inter-platoon spacing P, RKazerooni & Ploeg 2015 [16] Join, LaneReduction, GapOpen, GapClose Design of interaction protocols for LaneReduction and JoinMiddle, Analysis of velocity profiles P, RRajamani et al. 2000 [7] Join, Leave, LaneChange (FSM) Lateral and longitudinal control for Merge and Join, and LaneChange P, R

Best 2012 [17] -Rapid high-speed lane change for obstacle avoidance,

proposal of open-loop controller for steering instead of emergency brakingR

Choi & Swaroop 2000 [18] - Assessing coordinated emergency braking in platoons R

Frankel et al. 1996 [19]Merge, Split,LaneChange

Proposal of safety-ensuring controllers for Merge, Split,

and LaneChange as FSM, textual description of manoeuvresR

Godbole et al. 1995 [2] Join, Leave (textual) On- and off-ramp in AHS with dedicated lane for AVs RGoli & Eskandarian 2014 [20] Merge, LaneChange Multi-merge manoeuvre (multiple vehicles at one), lateral trajectory generation and execution via PID RHuang & Chen 2001 [21] Merge, Split Investigates the safety of Merge and Split for emergency braking into different stages of the manoeuvres R

Kato et al. 2002 [22]Merge, Leave,LaneReduction

Investigation of velocity profiles for merging, obstacle avoidance, leaving, and Stop&Go R

Li et al. 1997 [23] -Longitudinal control laws with focus on safety that can be

adjusted through parameters for changing external conditionsR

Murthy & Masrur 2016 [24],

Murthy & Masrur 2017 [25]Emergency Brake Coordinated emergency braking in platoons considering the weakest vehicle in the platoon R

Naranjo et al. 2008 /citenaranjo2008lane LaneChange Applying fuzzy controller lateral and longitudinal control in LaneChange manoeuvre for overtaking R

Rai et al. 2015 [26]

Merge,

LaneChange,Overtake

Concept of virtual leader to command synchronised lane changes,

collision avoidance through potential-field controllerR

Sun et al. 2003 [27]

LaneChange,

PlatoonChange,GapOpen, GapClose

Manoeuvre to directly switch from one platoon to other platoon on

adjacent lane, controller design for gap making and closingR

Swaroop & Yoon 1999 [28] Emergency Brake and Emergency LaneChangeController that couples braking and lane changing in emergency situations

through V2V communication for higher safetyR

Usman & Kunwar 2009 [29] Overtake Methodology for online generation of driving trajectories for overtaking manoeuvres RWang et al. 2017 [30] JoinMiddle, GapOpen, GapClose Trajectories for JoinMiddle for minimizing carbon emissions R* Focus of the paper, C = Communication, R = Regulation Layer, P = Platooning Layer

Figure 4: Relations of Key Deficits, Design Principles,and Design Goals for creating the SEAD framework.

ceptual depth within and among manoeuvre de-scriptions require to re-frame the manoeuvres be-fore comparison.

• Differing verbal descriptions: Differing verbal de-scriptions for equivalent conceptual componentsrequire the manual alignment of terms beforecomparison.

• Repetitive patterns: Repetitive action-communication-patterns within and amongmanoeuvres make manoeuvres more complex toread and tedious to be described.

• Complex synchronisation: The complex synchro-nisation between multiple role-specific FSM inone manoeuvre is challenging. This makes it hardto understand the collaborative aspect of a ma-noeuvre. Besides, it poses the threat of unstablestates due to unforeseen circumstances.

For the SEAD framework to achieve practicalitywhile resolving these deficits, we defined three designgoals. The goals outline how we define practicality forthe framework and give guidance in making all designdecisions. The three qualitative goals are Flexibility,Simplicity, and Stability.

• Flexibility: The framework must be capable ofdescribing all manoeuvres in the current state ofliterature. Any design decision, thus, must en-sure that the flexibility of describing manoeuvresis maintained and that restrictions are minimised.

• Simplicity: The prime use case of the frameworkis reading and formulating new or alternative ma-noeuvres. Any design decision, thus, must pro-mote the simplicity of reading and formulatingmanoeuvres.

• Stability: The stability of manoeuvre designs iscrucial, meaning that the design shall not allowfor manoeuvres that end in an undefined stateif unexpected driving situations occur. Any de-sign decision, thus, must foster the stability ofmanoeuvres for any possible interruption or ex-ception.

Given the postulated requirements, we derived fourmajor design principles that help to resolve the cur-rent shortcomings and to fulfil the design goals. Thesecan be summarised under the four terms Standardi-sation, Encapsulation, Abstraction, and Decoupling.The subsequent sections explain these principles in

5

greater detail and interrelate them with the estab-lished design goals and identified deficits.

Standardisation

As stated above, one prime issue in defining ma-noeuvres is the vastly varying terminology for equalconceptual components. These components can bestates within an FSM, V2V platooning messages orinherent reasons for state transitions such as au-tonomous decisions. Our framework resolves the lackof standardisation by introducing a finite set of sym-bols for these conceptual components. More specifi-cally, the SEAD framework provides a syntax for de-scribing vehicle actions, messages, and internal statetransition triggers. The main requirement for thisstandardisation is the universal comprehensibility re-gardless of context or background.

The principle of Standardisation will mainly be af-fected by the design goals Flexibility and Simplic-ity. Although Standardisation will introduce syntacticrule sets, the standardised framework must be capa-ble of expressing a sufficient conceptual depth not toobstruct the Flexibility goal. Besides, the Standard-isation should also promote Simplicity, meaning thatthe standardised terms must be intuitively comprehen-sible and easy to grasp without the need for extensivepreparation. The aim is that a person with no priorexperience with the SEAD framework must be able tounderstand the manoeuvres formulated using it.

Encapsulation

Throughout manoeuvre descriptions, we identifiedvarious repetitive patterns that include vehicle actionsand inter-vehicle communication. The principle of En-capsulation will help pack these patterns into reusableblocks whereas one block may contain autonomousactivities of one vehicle or synchronised actions ofmultiple vehicles. Moreover, these sub-manoeuvreswill mainly comprise actions and states of equal con-ceptual depth. This helps in resolving the problemsof varying conceptual depth, repetitive patterns, andcomplex synchronisation.

The Encapsulation will be influenced by all three de-sign goals. Following the design goal of Flexibility, theEncapsulation of intertwined action-communicationpatterns must not impose manoeuvre-design restric-tions. Thus, sub-manoeuvres on the lowest levelmust express the most fundamental patterns exhaus-tively. Thereby, Encapsulation will greatly promoteSimplicity as it will allow reusing behavioural pat-terns without the need for redesigning them. Thisrequires equipping sub-manoeuvres with a suitable in-terface that allows for integrating them into higher-order structures. Lastly, to achieve Stability, the sub-manoeuvres must be designed to always lead to pre-dictable outcomes that can be handled by any context.

Abstraction

Extending Encapsulation, the principle of Ab-straction will allow to reuse the encapsulated sub-manoeuvres within structures of conceptually higherlevels and to encapsulate these higher order structuresinto reusable blocks. This recursive re-usage allows for

arbitrarily complex structures whereas every level ofconceptual depth can be designed separately withoutthe need to operate on different levels at once. Ab-straction helps to resolve the deficits of varying con-ceptual depth and handling repetitive patterns.

As every system that re-frames complexity throughhierarchical depth, our framework imposes certainrestrictions. Nevertheless, it shall fulfil the designgoal of Flexibility, meaning that every abstractionwill be carefully evaluated. On the other hand, theAbstraction principle fosters Simplicity as the majorpart of the manoeuvre design process takes place atthe higher levels of abstraction. This allows buildinghighly complex manoeuvres with relatively low effort.

Decoupling

Lastly, the Decoupling principle will allow describ-ing complex manoeuvres entailing two or more vehi-cles from the perspective of the platoon leader. TheSEAD framework, and specifically the Encapsulationprinciple, ensures that this single-sided descriptionsuffices to describe the behaviour of all vehicles. Morespecifically, the utilized master-slave structure leadsto a general universal description of the reactive be-haviour of the slave (platoon followers or free vehi-cles) while manoeuvres are only defined and steeredby the master (platoon leader). This principle, in con-sequence, resolves the need for synchronising multiplemanoeuvre descriptions.

Decoupling will considerably facilitate the processof reading and describing manoeuvres as both actionsmust only be performed from the leader perspective.This greatly drives the goal of Simplicity. However,designing the reactive behaviour of the slave-vehiclesmust be very comprehensive and elaborate in order tofulfil the design goal of Flexibility.

4 Framework Building Blocks

In this section, we will give a detailed description ofthe building blocks that make up the SEAD frame-work. Before we present each building block in abottom-up fashion, we will describe a few propertiesof the the system to facilitate its overall comprehen-sion:

Scope: The described platooning framework doesnot include high level decision-making processes suchas when to form a platoon or when to leave a platoon.This is the task of the Link Layer Interface (LLI) andcould either be computed inside an autonomous ve-hicle or be given in the form of commands issued byanother controlling entity. The framework at handwill only cover the platooning layer itself.

Stability: To ensure stability of the system, eachplatooning manoeuvre has to end in a stable state forall involved vehicles, regardless of manoeuvre’s suc-cess. We refer to these states as ’stable idle states’ incontrast to ’unstable idle states’ which are states dur-ing a manoeuvre when a vehicle is waiting for an ac-tion of another vehicle. These stable idle states can be

6

Figure 5: Overview of the hierarchical structure of the SEAD Framework. The figure provides an examplewhere two vehicles, a platoon leader (left) and a temporary leader (right), perform a collaborative manoeuvre.

Platoon Leader (PL), Platoon Follower (PF), or FreeVehicle (FV). When a vehicle is waiting for an instruc-tion or action from another vehicle while performing amanoeuvre their respective unstable idle state wouldbe WPL, WPF, and WFV. Additionally, we make useof the unstable idle state Temporary Platoon Leader(TPL) to increase stability [10] when manoeuvres areaborted. Only when a vehicle is in a stable idle state(i.e., not currently performing a manoeuvre) is it avail-able to receive commands from the LLI.

Control: For every manoeuvre, we assume it tobe carried out in a master-slave fashion, that is, onevehicle (naturally, the platoon leader) issues orders tothe other vehicle(s). This does, however, not meanthat manoeuvres can only be initiated by the platoonleader, it merely describes the control flow once themanoeuvre has started.

Communication We assume the existence of anunderlying communication system that provides mes-sage primitives such as described by [5]. Thesemessages include Requests (REQ), orders (ORD),done-confirmation (DN), abort (ABT), and accep-tance/rejection (ACK/NACK). We abstract awayfrom modelling the physical transmission of messages

and assume perfect communication. To implementthe concept of a Temporary Platoon Leader (TPL),an additional specialised message type TMPL SPLITforces the split of a TPL and aborts the manoeuvrethat is currently being processed. REQ, ORD andDN messages can include additional information asrequired by the system, e.g., the size of the gap a ve-hicle is ordered to open. We further assume that theunderlying protocols can ensure that the successfultransmission of messages. If this cannot be ensured,then the sub-manoeuvres can be extended by addingrespective time-out states and abort transitions.

4.1 Framework Overview

Figure 5 provides an overview of the SEAD frameworkand illustrates its hierarchical structure according tothe paradigm of hierarchical state machines. The en-tire framework could be expressed as one big state ma-chine, however, the transitions and states are designedin a way to enable all four SEAD principles (Standard-isation, Encapsulation, Abstraction, and Decoupling).The different layers can therefore be seen as differ-ent zoom levels or views of the platooning behaviour

7

definition for autonomous vehicles. In the followingsections, we will introduce and explain the frameworkin a bottom-up fashion.

4.2 Action Primitives

The lowest layer of the framework is composed of ac-tion primitives which are actions that directly affectthe physical or logical state of a vehicle. We differ-entiate between physical primitives, state primitives,and other primitives. The physical primitives are thedirect interface to the regulation layer and affect thephysical state of a vehicle, i.e, the vehicle’s positionor speed. State primitives affect the role of the vehi-cle, i.e. whether it acts as a platoon leader or platoonfollower. They are needed to transition a vehicle fromand to different idle states (e.g., at the end of a ma-noeuvre or when the vehicle needs to wait for instruc-tions from another vehicle). Lastly, other primitivesare needed to either send messages, update platooninformation, or wait for certain events. Primitivesshould be designed in an orthogonal fashion, meaningthat one primitive cannot be expressed by a combi-nation of any other primitives. Table 2 provides anoverview of action primitives that could be found inthe state-of-the-art manoeuvre descriptions.

As the SEAD framework describes all actions on theplatooning layer, the physical primitives provide di-rections to the low-level control of the vehicle insteadof controlling the longitudinal dynamics directly. Forinstance, instead of setting the desired speed or accel-eration of the vehicle, the primitives set the desiredlocation. The path-following logic on the RegulationLayer will convert the target location into actionablecommands (accelerate, decelerate, steer left / right)for the physical layer.

4.3 Formulating Sub-Manoeuvres

With the list of idle states and action primitives, wecan now create sub-manoeuvres. A sub-manoeuvre en-capsulates reusable behavioural patterns that involvetwo or more vehicles and transitions at least one ofthe participating vehicles from one idle state into an-other. For each participating vehicle, the behaviour isdescribed through a sequence of primitives which con-stitute a sub-state machine. Sub-manoeuvres must de-sign action-communication patterns with the smallestreasonable scope to promote re-usability and thereforeachieve the goal of Flexibility.

To implement the principle of Decoupling, each sub-manoeuvre is split into two or more sub-state ma-chines, one for each vehicle participating. As SEADfollows the master-slave paradigm, one sub-state ma-chine controls the sub-manoeuvre (executed by theplatoon leader), the other sub-state machines purelyreact. The sub-state machines are connected and syn-chronised through V2V messages. This structure pro-motes the goal of Simplicity through the principles ofEncapsulation and Abstraction: Any sub-manoeuvre

can be reused without a thorough understanding ofthe inner workings once its behaviours and outcomesare defined. We will discuss this separation and de-coupling extensively in the Reactive State Machine(RSM) and the Proactive Manoeuvring Engine (PME)sections. The controlling sub-manoeuvre is denotedwith PME while the reactive ones are marked withRSM (as in Figure 5).

To fulfil the goal of Stability, sub-manoeuvres mustbe designed such that any possible scenario (success orabort) leads to a defined outcome for every participat-ing vehicle. Therefore, if one vehicle encounters a situ-ation that will prevent the successful completion of thesub-manoeuvre and causes an abort-result, V2V com-munication (or time-outs) must cause all other sub-state machines to terminate at the same abort-result.Due to a shared understanding of the sub-manoeuvreamong all vehicles, every vehicle is informed about thefinal state of all participants.

Figure 6: Sub-manoeuvre description and encapsula-tion for GAPCLOSE.

Figure 6 illustrates an example sub-manoeuvrewhere a platoon leader orders another vehicle in theplatoon to close the gap. For stability reasons, thevehicle that closes the gap is a temporary platoonleader, so that when the sub-manoeuvre fails, it willbe the platoon leader of all other vehicles behind. Thesub-manoeuvre includes two participants, the platoonleader (PL, vehicle A) and the temporary platoonleader (TPL, vehicle B). The sub-manoeuvre can con-clude in either Success (RS) or Abort 1 (RA1).

A initiates the sub-manoeuvre through command-ing B to close the gap by sending an ORD GAP-CLOSE message (A1) via V2V communication. Af-ter sending the message, A waits for the completion(A2). The message triggers B to execute the GAP-CLOSE sub-manoeuvre (B1). B sets its headwayto the requested intra-platoon distance and the reg-ulation layer starts to decrease the distance until itreaches the desired headway (B2).

In the success scenario, the desired headway isreached, B signals the completion of closing the gap tothe PL through sending a DN_GAPCLOSE (B3) andtransitions into the stable PF Idle State (B4). Thisconcludes the sub-manoeuvre for B with a success-

8

Table 2: List of Action Primitives derived and condensed from the state of the art.

Acronym Primitive Parameters Description Actor

Physical Primitives

MTP Move to position TR: Target object, RO: Relative offset Move to a position defined by a relative offset to a target (vehicle) and align speed FV, PL, TPLSH Set headway TH: Time headway or SH: Space headway Set the desired time or space ahead to preceding vehicle and adjust real distance PF, TPLState Primitives

BFV Become free vehicle Transitions the vehicle into a Free Vehicle All but FVBPL Become platoon leader Transitions the vehicle into a Platoon Leader All but PLBPF Become platoon follower Transitions vehicle into a Platoon Follower All but PFBTL Become temporary leader Transitions the vehicle into a Temporary Leader All but TPLSW Set Wait Sets idling state to corresponding waiting state FV, PL, PFUSW Unset Wait Sets waiting state to corresponding idling state WFV, WPL, WPFOther Primitives

W Wait E: Event to wait for, TO: Timeout Waits for an event to occur, a message, or for a timeout AllSND Send Message M: Message, R: Receiver Sends a message to the receiver AllUPI Update platoon information Updates information about the platoon (number and order of followers etc.) PL*(W)FV: (Waiting) Free vehicle, (W)PF: (Waiting) Platoon Follower, (W)PL: (Waiting) Platoon Leader, TPL: Temporary Platoon Leader

result RS (B5). A receives the message and concludesthe sub-manoeuvre with a success-result RS (A3).

In the abort scenario, if closing the gap is takingtoo long, a timeout in A aborts the sub-manoeuvre.The timeout causes A to send an ABT message toB (A4) and to update the platoon information (A5).Afterwards, the sub-manoeuvres concludes for A withan abort-result RA1 (A6). B receives the messageand will initiate the sequence to split from the originalplatoon by transitioning into a PL (B6). Once B is aPL, the sub-manoeuvre also concludes for B with anabort-result A1 (B7).

The upper part (the pro-active part) and the lowerpart (the reactive part) of the sub-manoeuvre is encap-sulated into two reusable blocks (A7 and B8, respec-tively). These buildings blocks can then be used tobuild manoeuvres for the Proactive Manoeuvring En-gine (PME) and the Reactive State Machine (RSM).Due to the structure of the sub-manoeuvres, the ini-tiation of a PME part will always leads to initiationof the RSM part as well. This principle allows defin-ing manoeuvres from the perspective of the platoonleader without the need to describe the participant’sbehaviour. In the same fashion as in Figure 6, it is pos-sible to define a comprehensive set of sub-manoeuvresthat allows assembling complex manoeuvres with lim-ited number of restrictions. We have created an onlinerepository where we have made graphical depictions ofmanoeuvres and sub manoeuvres as well as their ma-chine readable descriptions (see Section Section 4.8)publicly available 1.

4.4 Formulating Manoeuvres

To promote the design goal of Simplicity and due tothe master-slave paradigm of SEAD, a manoeuvreonly needs to be described from the perspective ofthe platoon leader. The behaviour of the other partic-ipants is defined in the sub-manoeuvres and the initi-ation of these sub-manoeuvres is done by the platoonleader via V2V messages. A sequential manoeuvre(see Section 4.4.1 how to define simultaneous manoeu-vres) is a chain of sub-manoeuvres, where the transi-tion to the next sub-manoeuvre depends on the resultof the previous one. Figure 7 shows the formulation

1The library can be found at https://github.com/sead-framework/manoeuvre-catalogue

of the JOIN TAIL manoeuvre as it was also describedin Figure 2.

Figure 7: Description of the JOIN TAIL manoeuvreaccording to the PME logic.

In this illustration, the chain of sub-manoeuvres de-scribes the entire manoeuvre. The blue lower part ofthe sub-manoeuvre boxes specifies the participatingvehicles according to the notation in Table 2 whereasvehicle A (VA) is not specified since it is always partof the manoeuvre as the PL, and vehicle B (VB) is theparticipating vehicle. The JOIN TAIL manoeuvre re-quires no additional actions in case of an abort andwill conclude in a stable state achieved through theabort-architecture within the sub-manoeuvres. Moreelaborate manoeuvres such as the JOIN MIDDLE re-quire more sophisticated abort structures (e.g., a GAPCLOSE for a platoon follower if the joining vehicle wasunable to lane change into the platoon). This is nec-essary to ensure that no vehicle will be in an unstableidle state once the manoeuvre is finished.

Defining manoeuvres in this fashion largely pro-motes Simplicity as a manoeuvre can be describedfrom the leader’s point of view while the reactive partof all sub manoeuvres (also referred to as the universalRSM) takes care of the participating vehicles’ perspec-tive.

4.4.1 Simultaneous Manoeuvres

Manoeuvres with two or more participating vehiclescan potentially benefit from the parallel execution ofsub-manoeuvres. To facilitate this, the SEAD frame-work introduces a wrapper for the simultaneous exe-cution, referred to as the SIM WRAPPER. This con-struct can involve an arbitrary number of simultane-ous sub-manoeuvres whereas every sub-manoeuvres’controlling part (the upper part in Figure 6) is exe-cuted by the same leader and the reactive portion (thelower part in the same figure) is executed by the partic-ipants. Two simultaneous sub-manoeuvres, however,cannot involve the same participating vehicle.

9

To comply with the requirement that a state ma-chine can only be in one state, the SIM WRAPPERcan be understood as a product state machine of thecontrolling portions of all involved sub-manoeuvres.Since the reactive portion is executed in separate ve-hicles through the Decoupling principle, they occurin separated state machines in distinct systems. Theexecution result can be any element from the Carte-sian product of all execution result sets from all sub-manoeuvres.

4.5 Idle States and Super-States

With the definition of idle states and sub-manoeuvres,it is possible to define them together to derive a state-machine on an abstraction level that clearly showshow the vehicle can transition from one idle state toanother via which sub-manoeuvre. We combine theidle state and its associated sub-manoeuvres (i.e., thesub-manoeuvres that a vehicle can execute if it is inthe idle state upon reception of a V2V message) intoan idle super-state. This concept is shown in Figure 8,where the idle state WFV (Waiting Free Vehicle) andthree sub-manoeuvres LC_BPF (Lane Change & Be-come Platoon Follower), MOVETOPOS (Move to Po-sition), and ATTACH are all combined into a super-state. This superstate can only be left through the suc-cessful or unsuccessful execution of sub-manoeuvres orwhen a time-out occurs.

Every stable Idle State (FV, PF, PL) has an idlingsuperstate. Within this superstate, the idle state willbe referred to as a LLI (Link Layer Interface) idlestate, because in these states, the vehicle can make(or receive) high-level decisions to carry out collabora-tive actions, for instance, joining or leaving a platoon,the decisions for which are made in the Link Layer.When the vehicle is in an unstable idle state (i.e.,WFV, WPF, WPL, TPL), thus in a manoeuvre, theLLI is inactive because manoeuvre initiation is onlypossible when the vehicle is not already performing amanoeuvre. Since this paper focuses on the PlatoonLayer and the LLI models the Link Layer, the innerworkings of the LLI will not be covered here.

Figure 8: Definition of the WFV Idle Superstate. Itcontains the WFV LLI Idle state as well as the sub-manoeuvres that can be performed by the WFV totransition into another Idle State.

4.6 Reactive State Machine (RSM)

The combination of all idle superstates into one biginterconnected state-machine yields the so-called Re-active State Machine (RSM), which can be seen as acomplete behaviour definition for all platooning vehi-cles except the platoon leader. As the platoon leadercoordinates and controls the manoeuvres, this state-machine is called reactive as it reacts to what theleader is doing. Figure Figure 9 shows the completeRSM for a platooning system which supports a num-ber of basic sub manoeuvres. For better readability,we chose sub manoeuvres as the abstraction level inthis illustration, however, each of the sub manoeuvreboxes could be replaced by the entire sub manoeuvredefinition (e.g., Figure 6.

The RSM describes the universal reactive behaviourof any vehicle for any manoeuvre that can be built us-ing sub-manoeuvres as building blocks. However, theRSM describes only the decoupled reactive behaviour(as indicated by the RSM in any sub-manoeuvre box).It does not implement how the manoeuvre is logi-cally performed, i.e. the sequence of sub-manoeuvrescomprising a manoeuvre. This implements the firsthalf of the Decoupling principle. The second half ofDecoupling, the formulation and control of manoeu-vres, is implemented by a complementary structurethat steers manoeuvres, namely the Proactive Ma-noeuvring Engine (PME).

The introduction of the RSM strongly promotes thegoal of Stability. As can be seen in Figure 9, the RSMdefines the behaviour in case of an abort for every sub-manoeuvre. This structure, thus, always brings thevehicle to a defined state in whichever way a manoeu-vre terminates. According to the Abstraction princi-ple, the RSM reuses sub-manoeuvres, which leads toall building blocks in the RSM being on an equivalentconceptual level. This directly mitigates the two keyshortcomings of varying conceptual depth and repet-itive patterns. Since the structure and design of thesub-manoeuvres is aligned with the goal of Flexibility,the RSM introduces no further restrictions regardingthis concern.

4.7 Proactive Manoeuvring Engine(PME)

While both proactive and reactive behaviour defini-tions can be combined into one state-machine, weseparate them for the sake of Simplicity and Decou-pling. To this end, the Proactive Manoeuvring En-gine (PME) complements the reactive behaviour ofthe RSM (as can be seen in the left bottom of Figure 9they are indeed connected). The PME is therefore anextension to the PL’s RSM behaviour and is respon-sible for the coordination of platooning manoeuvres.

Figure 10 shows the PL LLI with the connectionto the RSM part (Figure 9) on the right side andthe entire PME on the left side. The level of ab-straction chosen in this figure is on the manoeuvre

10

Figure 9: Reactive State Machine (RSM). It describes the reactive behaviour by combining all sub-manoeuvres.

layer with the example at hand supporting the JOIN,LEAVE and SPLIT manoeuvres. These manoeuvreboxes could be extended to their respective containedsub-manoeuvres (or even further to include the entirecontrolling part of each sub-manoeuvre), however, Ab-straction and Decoupling allow us to illustrate the pla-tooning system in a more comprehensible way. ThePME combines the manoeuvre schemes of all manoeu-vres and steers the manoeuvres from the perspectiveof the PL. Manoeuvres are initiated through the LLIof the PL either directly (direct init. in Figure 10)or through a request REQ that triggers a NEGOTI-ATE sub-manoeuvre. When adding a new manoeuvre,rules in the LLI must define when it will be called (i.e.which REQ message evokes a NEGOTIATE or whichconditions triggers a direct init.) as illustrated in Fig-ure 10.

Only manoeuvres that concern exclusively platoonfollowers can be instantiated directly by the PL. Forinstance, a PL cannot command an FV to join itsplatoon without a prior request of the FV to join.This idea imposes that joining is always initiatedthrough an FV. However, by designing an additional

sub-manoeuvre where the PL requests an FV to join,the SEAD framework can also adapt to this paradigm.

4.8 Manoeuvre Design Language

Although the visual description of manoeuvres andsub-manoeuvres is easily comprehensible for humans,machines will not be able to process it. To allow flexi-bly redesigning manoeuvres and sub-manoeuvres, wehave developed a Manoeuvre Design Language (MDL)that directly translates from and into a graphical rep-resentation. In the future, a graphical editor to cre-ate and export manoeuvres and sub-manoeuvres asJSON MDL files will help to easily design manoeuvresgraphically and to directly feed them into simulationsystems. The simulation system parses the MDL fileand generates the code required for the execution ofmanoeuvres according to the SEAD framework. TheMDL is based on JSON and was inspired by the syn-tax and structure of the Amazon States Language [].One JSON MDL file has a unique ID (or action ID)and describes a (sub-)manoeuvre following a fixed syn-tax. The syntax of the language is outside of the scope

11

Figure 10: Proactive Manoeuvring Engine (PME). A manoeuvre can either be initiated through an acknowl-edged request through NEGOTIATE or directly through the LLI of the PL.

of this paper but can be accessed in [33]

5 Conclusion and Future Work

This paper introduces the SEAD framework that sim-plifies the formulation of manoeuvres for vehicle pla-tooning. It is based on the four principles of Stan-dardisation, Encapsulation, Abstraction and Decou-pling (SEAD). As previous research has shown [1],vehicle platooning has the potential to substantiallyincrease road capacity and traffic throughput, provid-ing a potential solution for traffic systems to adapt tothe ever-increasing traffic demand. Although vehicleplatooning is a promising concept, it remains challeng-ing to define and describe collaborative manoeuvres.This poses a bottleneck in the development pace ofthe platooning concept and hampers its applicabilityin real-world scenarios.

The design of the SEAD framework was conceptu-alised to resolve four key shortcomings of the state-of-the-art description of manoeuvres using coupledstate machines: First, as a manoeuvre description con-sists of one state machine per participant, the readermust synchronise the state machines to understandthe manoeuvre. Second, the investigated schemas re-veal varying conceptual depth within and among ma-noeuvre description as well as, third, differing verbaldescriptions of equivalent components. This hetero-geneity makes it difficult to understand and comparemanoeuvres. Finally, various action-communicationpatterns surfaced in multiple manoeuvre descriptions,making them seem more complex than they are.

The SEAD framework is a first step to formalisethe Platoon Layer of an Automated Highway System.It provides the means to conduct further research onthe performance of manoeuvre variations, alternativesand platoon forming strategies. There are two mainfuture research fields involving the proposed frame-work.

Improving and Extending the SEAD Frame-

work

Once the required simulation tools for platooningin urban environments are in place, further buildingblocks may be designed extending the SEAD frame-work. The framework will allow formulating complexurban manoeuvres such as LEAVE MIDDLE ANDTURN LEFT (or LMTL), yet the further develop-ment of primitives, sub-manoeuvres, and communica-tion patterns will be required.

To increase the adoptability and usability of theSEAD framework, future research could focus on de-veloping a stand-alone application-agnostic tool thatmodels the Platoon Layer according to the presentedframework. However, since the Platoon Layer and theRegulation Layer are closely interconnected throughthe Action Primitives, an elaborate communicationinterface between these two layers needs to be de-veloped to allow for modularisation. The resultingmodule could then be optimised in simulations and,in the further future, be deployed within the vehiclesoftware.

Furthermore, although the proposed frameworkallows defining elaborate abort structures for ma-noeuvres and sub-manoeuvres, it does not proposean abort-and-retry structure. Once elaborate mod-els are in place to evaluate if a second attemptcould be successful, higher-order manoeuvres and re-modularisation of certain sequential parts of a ma-noeuvre provide the opportunity to implement suchabort-and-retry structures.

Empowering Further Studies

As mentioned before, the biggest advantage ofthe SEAD framework is its capability of design-ing manoeuvre variants and alternatives through re-arranging the sub-manoeuvres once all building blocksare implemented and the RSM defined all requiredstate transitions. This allows for various dynamic in-vestigations.

12

For instance, traffic simulators implementing theframework such as BEHAVE [34] could provide ameans to identify the most efficient alternative of amanoeuvre through simulating all possible alterna-tives and measuring the execution time, success rate,and traffic flow influence of the alternatives. Usingthe same approach, different platoon formation strate-gies (Weakest-in-Front, Last-in-at-Tail, dynamic con-textual strategies etc.) could be investigated regard-ing their influence on the overall traffic flow. TheSEAD architecture has already been implemented andis a critical part of the Autonomous Vehicle DriverModel architecture described in [35].

The proposed framework utilises a timeout-strategyso that manoeuvres are not leading into a deadlock if,for instance, a human-driven vehicle is blocking theway to complete a manoeuvre. The timeout-strategy,however, is a mechanism to ensure deadlock-freeness.Research may investigate further models to identifyblocking situations with a low likelihood of manoeuvresuccess to interrupt the manoeuvre using as a triggeran event rather than a time-out. Otherwise, simula-tions may allow to numerically optimise the time-outparameters with, for instance, the overall traffic flowas the objective variable to maximise.

After all, platoon manoeuvring is a powerful yetcomplex technique to fulfil the ever-increasing trafficdemand with the given capacities we have. Furtherresearch will have to investigate many more gaps andfind the most effective strategies to maximise trafficthroughput. To unlock the full potential of platoon-ing, the SEAD framework aims to pave the way forthis future research by providing a formalisation of theplatooning logic and simplifying the way how new ma-noeuvres are created and existing ones are comparedand optimised.

References

[1] P. Varaiya, “Smart cars on smart roads: prob-lems of control,” IEEE Transactions on auto-matic control, vol. 38, no. 2, pp. 195–207, 1993.

[2] D. N. Godbole, F. Eskafi, E. Singh, andP. Varaiya, “Design of entry and exit maneuversfor ivhs,” in Proceedings of 1995 American Con-trol Conference-ACC’95, vol. 5. IEEE, 1995, pp.3576–3580.

[3] A. Hsu, F. Eskafi, S. Sachs, and P. Varaiya, “Pro-tocol design for an automated highway system,”Discrete Event Dynamic Systems, vol. 2, no. 3-4,pp. 183–206, 1993.

[4] J. Ivanchev, D. Zehe, V. Viswanathan, S. Nair,and A. Knoll, “Bisos: Backwards incremental sys-tem optimum search algorithm for fast sociallyoptimal traffic assignment,” in 2016 IEEE 19thInternational Conference on Intelligent Trans-portation Systems (ITSC). IEEE, 2016, pp.2137–2142.

[5] M. Amoozadeh, H. Deng, C.-N. Chuah, H. M.Zhang, and D. Ghosal, “Platoon managementwith cooperative adaptive cruise control enabledby vanet,” Vehicular communications, vol. 2,no. 2, pp. 110–123, 2015.

[6] A. Hsu, S. Sachs, F. Eskafi, and P. Varaiya, “Thedesign of platoon maneuvers for ivhs,” in 1991American Control Conference. IEEE, 1991, pp.2545–2550.

[7] R. Rajamani, H.-S. Tan, B. K. Law, and W.-B.Zhang, “Demonstration of integrated longitudi-nal and lateral control for the operation of auto-mated vehicles in platoons,” IEEE Transactionson Control Systems Technology, vol. 8, no. 4, pp.695–708, 2000.

[8] E. M. Clarke and R. P. Kurshan, “Computer-aided verification,” IEEE Spectrum, vol. 33, no. 6,pp. 61–67, 1996.

[9] H. H. Bengtsson, L. Chen, A. Voronov, andC. Englund, “Interaction protocol for highwayplatoon merge,” in 2015 IEEE 18th Interna-tional Conference on Intelligent TransportationSystems. IEEE, 2015, pp. 1971–1976.

[10] M. Segata, B. Bloessl, S. Joerer, F. Dressler, andR. L. Cigno, “Supporting platooning maneuversthrough ivc: An initial protocol analysis for thejoin maneuver,” in 2014 11th Annual conferenceon wireless on-demand network systems and ser-vices (WONS). IEEE, 2014, pp. 130–137.

[11] X.-Y. Lu and J. K. Hedrick, “Longitudinal con-trol algorithm for automated vehicle merging,”International Journal of Control, vol. 76, no. 2,pp. 193–202, 2003.

[12] X.-Y. Lu, H.-S. Tan, S. E. Shladover, and J. K.Hedrick, “Automated vehicle merging maneuverimplementation for ahs,” Vehicle System Dynam-ics, vol. 41, no. 2, pp. 85–107, 2004.

[13] C. Nowakowski, D. Thompson, S. E. Shladover,A. Kailas, and X.-Y. Lu, “Operational conceptsfor truck maneuvers with cooperative adaptivecruise control,” Transportation Research Record,vol. 2559, no. 1, pp. 57–64, 2016.

[14] H.-H. Hsu and A. Liu, “Platoon lane changemaneuvers for automated highway systems,” inIEEE Conference on Robotics, Automation andMechatronics, 2004., vol. 2. IEEE, 2004, pp.780–785.

[15] H. C.-H. Hsu and A. Liu, “Kinematic design forplatoon-lane-change maneuvers,” IEEE Trans-actions on Intelligent Transportation Systems,vol. 9, no. 1, pp. 185–190, 2008.

[16] E. S. Kazerooni and J. Ploeg, “Interaction proto-cols for cooperative merging and lane reduction

13

scenarios,” in 2015 IEEE 18th International Con-ference on Intelligent Transportation Systems.IEEE, 2015, pp. 1964–1970.

[17] M. C. Best, “Optimisation of high-speed crashavoidance in autonomous vehicles,” 2012.

[18] W. Choi and D. Swaroop, “Assessing the safetybenefits due to coordination amongst vehiclesduring an emergency braking maneuver,” in Pro-ceedings of the 2001 American Control Confer-ence.(Cat. No. 01CH37148), vol. 3. IEEE, 2001,pp. 2099–2104.

[19] J. Frankel, L. Alvarez, R. Horowitz, and P. Li,“Safety oriented maneuvers for ivhs,” Vehicle Sys-tem Dynamics, vol. 26, no. 4, pp. 271–299, 1996.

[20] M. Goli and A. Eskandarian, “Evaluation oflateral trajectories with different controllers formulti-vehicle merging in platoon,” in 2014 Inter-national Conference on Connected Vehicles andExpo (ICCVE). IEEE, 2014, pp. 673–678.

[21] A. Huang and Y. Chen, “Safe platoon controlof automated highway systems,” Proceedings ofthe Institution of Mechanical Engineers, Part I:Journal of systems and control engineering, vol.215, no. 5, pp. 531–543, 2001.

[22] S. Kato, S. Tsugawa, K. Tokuda, T. Matsui, andH. Fujii, “Vehicle control algorithms for cooper-ative driving with automated vehicles and inter-vehicle communications,” IEEE Transactions onintelligent transportation systems, vol. 3, no. 3,pp. 155–161, 2002.

[23] P. Li, L. Alvarez, and R. Horowitz, “Ahs safe con-trol laws for platoon leaders,” IEEE Transactionson Control Systems Technology, vol. 5, no. 6, pp.614–628, 1997.

[24] D. K. Murthy and A. Masrur, “Braking in closefollowing platoons: The law of the weakest,” in2016 Euromicro Conference on Digital SystemDesign (DSD). IEEE, 2016, pp. 613–620.

[25] ——, “A subplatooning strategy for safe brakingmaneuvers,” in 2017 Euromicro Conference onDigital System Design (DSD). IEEE, 2017, pp.375–382.

[26] R. Rai, B. Sharma, and J. Vanualailai, “Real andvirtual leader-follower strategies in lane changing,merging and overtaking maneuvers,” in 2015 2ndAsia-Pacific World Congress on Computer Sci-ence and Engineering (APWC on CSE). IEEE,2015, pp. 1–12.

[27] X. Sun, R. Horowitz, and C.-W. Tan, “An ef-ficient lane change maneuver for platoons ofvehicles in an automated highway system,” inASME 2003 International Mechanical Engineer-ing Congress and Exposition. American Society

of Mechanical Engineers Digital Collection, 2003,pp. 355–362.

[28] D. Swaroop and S. M. Yoon, “Integrated lat-eral and longitudinal vehicle control for an emer-gency lane change manoeuvre design,” Interna-tional Journal of Vehicle Design, vol. 21, no. 2-3,pp. 161–174, 1999.

[29] G. Usman and F. Kunwar, “Autonomous vehi-cle overtaking-an online solution,” in 2009 IEEEInternational Conference on Automation and Lo-gistics. IEEE, 2009, pp. 596–601.

[30] Z. Wang, G. Wu, P. Hao, K. Boriboonsomsin,and M. Barth, “Developing a platoon-wide eco-cooperative adaptive cruise control (cacc) sys-tem,” in 2017 IEEE Intelligent Vehicles Sympo-sium (IV). IEEE, 2017, pp. 1256–1261.

[31] C. Bergenhem, “Approaches for facilities layerprotocols for platooning,” in 2015 IEEE 18th In-ternational Conference on Intelligent Transporta-tion Systems. IEEE, 2015, pp. 1989–1994.

[32] IEEE, “IEEE Guide for Wireless Access in Ve-hicular Environments (WAVE) - Architecture,”IEEE, Std 1609.0-2013, 3 2014.

[33] C. DeBoeser, “Towards a Hierarchical State-Machine-Based Framework for Platoon Manoeu-vre Descriptions,” Master’s thesis, Technical Uni-versity of Munich, Munich, Germany, 2019.

[34] J. Ivanchev, T. Braud, D. Eckhoff, D. Zehe,A. Knoll, and A. Sangiovanni-Vincentelli, “Onthe Need for Novel Tools and Models for MixedTraffic Analysis,” in 26th International TransportSystem World Congress, Singapore, 2019.

[35] T. Braud, J. Ivanchev, C. Deboeser, A. Knoll,D. Eckhoff, and A. Sangiovanni-Vincentelli,“Avdm: A hierarchical command-and-control sys-tem architecture for cooperative autonomous ve-hicles in highways scenario using microscopic sim-ulations,” Autonomous Agents and Multi-AgentSystems, vol. 35, no. 1, pp. 1–30, 2021.

14