A Generic Interface Enabling Combinations of State-of-the-Art Path Planning and Tracking Algorithms

: In the development of Level 4 automated driving functions, very speciﬁc, but diverse, requirements with respect to the operational design domain have to be considered. In order to accelerate this development, it is advantageous to combine dedicated state-of-the-art software components, as building blocks in modular automated driving function architectures, instead of developing special solutions from scratch. However, e.g., in local motion planning and control, the combination of components is still limited in practice, due to necessary interface alignments, which might yield sub-optimal solutions and additional development overhead. The application of generic interfaces, which manage the data transfer between the software components, has the potential to avoid these drawbacks and hence, to further boost this development approach. This publication contributes such a generic interface concept between the local path planning and path tracking systems. The crucial point is a generalization of the lateral tracking error computation, based on an introduced error classiﬁcation. It substantiates the integration of an internal reference path representation into the interface, to resolve the component interdependencies. The resulting, proposed interface enables arbitrary combinations of components from a comprehensive set of state-of-the-art path planning and tracking algorithms. Two interface implementations are ﬁnally applied in an exemplary automated driving function assembly task.


Introduction
Automated driving (AD) has been a huge challenge over the last decades in research as well as in industry. However, estimations and expectations for final breakthroughs on the market have been continuously shifted, contrary to many announcements. An analytic look at the available products on the market reveals that SAE Level 2 [1] is still state-of-the-art in passenger cars, outdone in few applications to Level 3 for very restrictive applications (e.g., [2]). Level 4 automation, in particular for urban road networks, is still an open challenge (see [2]) and therefore in focus of current research. From a general perspective, the step from Level 3 to 4 is a shift from automated to autonomous driving. This step involves full environmental perception and decision making. Furthermore, the human driver can not be applied as safety fallback anymore. Consequently, it is a game changing development step. From implementation point of view a paradigm shift in system architecture is required since sensors must be shared between components and new concepts for multi-layer control software are required.
In contrast to the "under all conditions" requirement of Level 5 automation, which is quite problematic from a technical perspective, Level 4 automation solves the task of fully autonomous driving under clearly defined conditions, i.e., in a specified operational design domain (ODD). Different ODDs can be very diverse, e.g., valet parking and highway driving, and, hence, require a carefully matched AD function. From this point of view, a The interface design needs an overview on state-of-the-art components and algorithms. Therefore, the publication simultaneously features a survey contribution, in particular with respect to path tracking algorithms (from a specific point of view) and specific interpolation methods. The presented classification of lateral tracking error definitions based on a comprehensive set of state-of-the-art tracking controllers is essential for the proposed interface design, but also contributes to a better understanding of the impact of tracking error definition on the performance of a tracking controller. The proposed interface design, furthermore, may serve as conceptual model for the design of other interfaces in modular system architecture for AD functions.
In detail, the publication structures as follows: Section 2 outlines the general path tracking problem and identifies the lateral tracking error computation as a major challenge in the generic interface design. In order to tackle this challenge, Section 3 introduces a lateral tracking error classification approach. This proposed classification enables a generalized approach in tracking error computation (see Section 4), based on a concise set of three elementary path operations. This set is sufficient to cover a comprehensive set ot state-of-the-art path tracking controllers. Section 5 summarizes the contribution of the preliminary findings for the aimed interface design. Section 6 extends the interface requirements from the path planning side, yielding the final interface design concept in Section 7. Finally, in Section 8 a simple, exemplary ODD-based AD function assembly tasks is considered in order to demonstrate the proposed interface design and to substantiate its benefits. Appendixs A and B provide continuative theoretical basics on path parametrization and interpolation.

The Path Tracking Problem
Path tracking is an important sub-problem of motion control in automated driving tasks. In contrast to the more general trajectory tracking (see for example [11,12], (p. 172)) the trajectory is split into a time-independent, spatial information-the reference path-and a time-dependent function, which defines the reference position at a specific time along this path. A lateral controller applies steering commands to approach the reference paththe so-called path tracking. Concurrently a longitudinal controller applies vehicle speed adaptions in order to track the time-dependent reference position along the path. The basic assumption behind a separated lateral and longitudinal control is almost decoupled lateral and longitudinal vehicle dynamics. In fact, they are actually coupled due to the limited traction forces of the vehicle tires and the time-dependent actuation limitations (steering rate). Whereas this assumption is valid in low-and moderate-speed driving at dry roads, respectively in high-speed driving with low steering dynamics, it is not valid in highly dynamic maneuvers, like emergency evasions or when driving on an icy road.
There exists several surveys on the classification of state-of-the-art tracking controllers like [5,[13][14][15] and [6] (pp. . In general, the path tracking problem can be stated as follows: Given an planar reference path, which might be represented in a parametric way (cf. Appendix A) with respect to a curve parameter τ, the path tracking controller has to compute a steering actuation, e.g., a steering wheel angle, in order to make a the position of the vehicle to follow the reference path. In order to use classical control system design approaches an appropriated error vector has to be defined, based on the reference path and the vehicle pose. The vehicle pose consists of the vehicle position x(t), y(t) and heading ψ(t) and possibly more vehicle states, The error vector consists of a mandatory spatial tracking error (some lateral offset error) and optionally of additional error measures like an orientation error or curvature error. Some special control approaches, e.g., Model Predictive Control (MPC), furthermore, require several lateral tracking errors corresponding to vehicle pose predictions.
With respect to a specific control error, the path tracking controller defines a steering command δ(t), which shall control the tracking error to zero, and consequently make the vehicle to follow the reference path: There are various reasonable possibilities to the define a lateral tracking error (see Figure 2) based on different motivations. In general, there exists no unique mappings between different lateral errors. It is an important but little-noticed fact that both the error definition and the control law design have to be considered as degrees of freedom in control system design and impact the final tracking performance.
The computation of the tracking error depends on the reference path, which is provided by the motion planning system. Consequently, its constitution and quality are defined by another component, which yields an undesired dependency on the planning system. Therefore, it is reasonable to think about outsourcing the tracking error computation to a generic interface component. To do so, it is necessary to analyze state-of-the-art path tracking algorithms with respect to the applied lateral tracking error definition. A unique classification of the used tracking error definitions and a generalization of the tracking error computation based on this classification is a major step towards the intend generic interface, which is addressed in the next sections.

Tracking Error Classification
Based on the analysis of a comprehensive set of state-of-the-art path tracking controllers (cf. Table 2), the introduction of three general and comprehensible classifier sets are introduced (S vr : vehicle reference, S lh : look-ahead (direction and distance) and S eo : error orientation), which are applicable to classify these controllers and to analyze their differences.
These classifiers shall now be discussed in more detail, in order to summarize the corresponding motivation and the effects on the control design and control performance.

Vehicle Reference Point
The vehicle reference might be defined at an arbitrary point on the vehicle chassis. There is a set of common reference points, based on a single-track abstraction of a frontaxle-steered vehicle (see Figure 3) with different motivations:

•
Rear axle: A vehicle, in general, features non-holonomic dynamics. The rear axle is the point of the vehicle with the "most constrained" motion. Assuming zero lateral slip, the motion of the rear axle is aligned with the vehicle heading. Therefore, a constant zero tracking implies that also the vehicle heading is aligned to the reference path, which is a favorable tracking property. From control system theory the center of the rear axle is of interest, as it is a flat output of the system restricting on slip-free vehicle kinematics (see for example [11,16]). The turning radius of the rear axle in cornering is smaller than the turning radius of the front axle (see Figure 4). Therefore, the choice of the rear axle as a vehicle reference point, in general, implies potential undesired overshooting of the vehicle's front. • Front axle: If the vehicle reference point is set to the center of the front axle, the non-holonomic vehicle kinematics in principle do not have to be considered in the control design, as stopping and adjustment of the steering angle enables tracking of arbitrary reference paths within the limited turning radius. This enables a simplified control design, especially for low dynamic driving tasks as parking. A drawback of this reference point is the smaller turning radius of the rear axle in cornering (cf. rear axle reference point), which implies potentially undesired curve cutting. • Center of gravity: The choice of the center of gravity as a vehicle reference, simplifies the setup of the vehicle's equations of motion. Therefore, it is used in many control system design approaches. From tracking perspective its position, somewhere in the middle of the car is of interest, in order to minimize the total distance of all points with respect to the reference path. • Center of oscillations/percussion: In the center of oscillation or percussion, the translation and rotation impact of a lateral tire slip at the rear axle are in balance. Consequently, this point is of special interest in order to design control laws, which are robust with respect to lateral rear axle tires slip. The choice of this reference point is popular in tracking controllers designed for limit-handling, as racing applications (see for example [17,18]). For front-wheel-steered vehicles the position of the center of percussion with respect to the rear axle l CP is: where l CG is the distance of rear axle and center of gravity, m the vehicle mass and I zz the vehicle's inertia in the center of gravity with respect to the vertical vehicle axis.   The set of vehicle reference classifiers S vr , hence, can be summarized as: S vr = rear, front, CG, CP .

Look-Ahead
Due to the non-holonomic motion of a vehicle, reference points on the path parallel to the vehicle are out of reach without reverse driving or spacious maneuvers. Therefore, many tracking error definitions do not directly use the vehicle reference point to compute a lateral tracking error, but some point ahead of the vehicle reference point. The application of such a so-called look-ahead, or preview (see, for example, [19]), is a very natural behavior of human drivers. The look-ahead refers to the vehicle reference point and is defined by a look-ahead direction and a look-ahead distance. The introduction of a look-ahead enables preventive reaction to sudden direction changes of the reference path, which stabilizes the vehicle motion. As this becomes more crucial for higher vehicle speeds several tracking controllers (see, for example, [19][20][21][22]) use an adaptive, velocity dependent look-ahead distance, instead of a fixed distance. This is advantageous also if the tracking controller is applied in combination with simple motion planning systems, which do not provide a smooth path (cf. Section 8), since the look-ahead damps the impact of path discontinuities. In [23], the impact of this damping characteristic is analyzed with respect to control stability in frequency domain base on a linearized vehicle model. This damping characteristic at the same time reveals the main drawback of a look-ahead application. A smooth vehicle motion is achieved at the cost of worse tracking performance in the vicinity of the actual vehicle position (e.g., curve cutting). Even in the case of perfect reference tracking e lat (t) ≡ 0 the vehicle itself actually does not follow the planned reference path. This implies that planned reference path properties, like specific safety distances to obstacles, are withdrawn. If a tracking controller is applied in combination with a comprehensive motion planning system, consequently, one should carefully think about the application of a look-ahead in the tracking error definition. Three reasonable choices for the direction of a look-ahead appear (see Figure 5): • look-ahead towards the vehicle heading, • look-ahead towards the direction of motion in vehicle reference point, • and look-ahead towards the reference path in a certain distance.  Considering vehicle kinematics (see Figure 4), the absolute direction of motion ψ x in a vehicle reference point at distance l x in front of the rear axle (towards the vehicle heading ψ), with respect to a steering angle δ is: This direction is obviously equal to the vehicle heading at the rear axle (for l x = 0) and equal to the steering direction at the front axle (l x = l). The application of a lookahead extends the possibilities in achieving specific constitution of the final model-based tracking problem, as it is proposed for example in [12] (pp. 199-201) (front axle vehicle reference and a look-ahead in direction of motion): In this case, decoupling and inputoutput linearization can be achieved with a static feedback. The above considerations yield the set of look-ahead classifiers S lh : S lh = heading, motion, path .

Error Orientation
Based on a vehicle reference point and the optional look-ahead (direction and distance) the orientation of the tracking error needs to be defined in order to compute a lateral tracking error. Similar to the definition of look-ahead directions, reasonable orientations are: • perpendicular to the vehicle heading, • perpendicular to the direction of vehicle motion in the vehicle reference point, • perpendicular to the path.
For almost straight reference paths, different error orientations approximately coincide if the vehicle drives along the reference path. On the other hand, if the vehicle first has to approach the reference path, or drives along curvy path sections, differences reveal (see Figure 6). In summary the classification set for the error orientation is: The above definitions can be used to give a comprehensive definition of a lateral tracking error based on the classifiers vehicle reference, look-ahead (direction and distance) and error orientation in the combined set, according to (7), (9) and (10). Figure 6 exemplarily illustrates all possible error definitions for the vehicle reference at the front axle, i.e., for the set heading × S lh × S eo , as listed in Table 1. In the case of a look-ahead towards the path and an error orientation perpendicular to the path, the lateral error has to be defined either with respect to the vehicle heading or motion (see errors e p,p(h) and e p,p(m) ). Based on given coordinates of the vehicle reference point, a specified look-ahead distance and direction and error orientation define a reference point on the path. In addition to the lateral tracking error, this reference point can be used to compute further error measures like an orientation or curvature error. In [24], the choice of an appropriate heading error is discussed and its impact on the tracking performance is analyzed.   Table 1), i.e., the classification set {front × S lh × Seo}.

Application to State-of-the-Art Tracking Controller
To prove the applicability of the proposed tracking error definition classification, it is applied to a comprehensive set of state-the-art tracking controllers. Table 2 lists the classification according to the specified classifiers. Table 2. Tracking error classification of state-of-the-art path tracking controllers.

Controller
Vehicle Ref.

Look-Ahead Error Orient.
Hoffmann (Stanley) [25], Kolb [26] front no path Sun [27,28], Kritayakirane [17], CG no path Chen [29], Hu [30] Bruschetta [31] Chatzikomis [14], Xu [19], Zhang [32] CG no heading Hiraoka [33] CP no path Tieber [34], Samson [35], rear no path Dominguez [36], Solea [37] Nestlinger [20], Ackermann [38], CG heading heading ARGO [21], Guldner [23], Yuan [22] Elkaim [39] CG heading path Solea [37] rear motion path Sentouh [40] CG motion motion Coulter (Pure-pursuit) [41] rear path heading While Table 2 shows the application of various vehicle reference points, and lookahead directions, most tracking controllers are based on an error orientation perpendicular to the reference path or to the vehicle heading. Only one of the considered controllers [40] is based on an error orientation perpendicular to the vehicle motion in the reference point. A possible explanation for this is the fact that direct measurement of the actual vehicle motion direction is challenging due to the side slip of the tires. As an alternative, an estimation based on the yaw rate has to be used. In fact, in [40], the authors do not propose a steering controller for application in an autonomous vehicle but propose a human driver model for simulation purpose. In [42], a hybrid concept consisting of an Pure-pursuit and Stanley controller is proposed in order to combine a tracking error definition with look-ahead and without look-ahead. In [17], the control law is designed with a vehicle reference point in the center of percussion. The used lateral control error e CP , however, is a projection of the distance of the center of gravity to the path e CG : according to the distance between center of gravity and center of percussion d CG,CP and the heading error e ψ . Therefore, the vehicle reference point is assigned to the center of gravity.
In [27,28,31], an MPC is applied for path tracking. In every MPC step, actuation signals are optimized with respect to a specific cost function on a prediction horizon. In general, the cost function includes a deviation from the reference path, i.e., a lateral tracking error. Instead of an evaluation of the tracking error at a single vehicle pose (cf. Figure 8), hence additionally an evaluation at several predicted vehicle poses is required. The choice of the single introduced classifiers can be considered as part of the control parametrization. As Figure 6 indicates, the actual control error computation is defined by specific geometrical operations with respect to the current vehicle pose, the control parametrization and the provided reference path. A generalization of the tracking error computation is presented in the next section.

Tracking Error Computation
Based on a generalized reference point, which already considers an optional vehicleoriented look-ahead (except for a look-ahead towards to reference path), it is noticeable that despite the various possibilities in the tracking error definition the actual error computation can be handled with only five geometric operations (see Tables 3 and 4 and Figure 7).
The operations a (intersection of two lines) and c (projection of a point on a line) do not depend on the reference path and have simple analytic solutions. Contrary, the operations A (intersection of the reference path with a line), B (intersection of the reference path and a circle) and C (point projection onto the reference path) depend on the path representation (cf. Appendix A). Hence, the reference path representation also determines the resulting computational complexity. Some general statements can be made on this path operations.

Intersection of Reference Path and a Straight Line
After performing a translation and rotation of the path, this operation reveals as common root finding problem, which can, in general, not be solved analytically, for example in case of a higher order polynomial reference path. However, many well-established numeric algorithms like Newton-method, bisection-method or Brent-method, can be used to compute arbitrarily exact approximations to the solution of this problem (see, for example, [43][44][45]). The solution of this path operation is neither unique nor it exists for sure. Hence, tracking controllers relying on this path operation inevitably have to define a fallback solution for the control law. The fallback solution, e.g., a constant curvature turn, has to ensure the convergence to a region where the path operation yields a solution. With respect to the uniqueness, it is reasonable to use the closest solution.

Intersection of Reference Path and a Circle
From an analytic perspective, this operation can be considered equivalent to operation A after performing a transformation of the corresponding reference path section into polar coordinates, which is challenging for an arbitrarily parameterized path. From numerical perspective, it might also be considered as a generalization of the shortest-distance-problem (cf. operation C), searching for a fixed given distance to the reference path instead of the shortest distance. The solution of this path operation in general yields at least two solutions, which can be prioritized following again the most-progress-on-path principle. The solution of this path operation obviously does not exist if the shortest distance between the center point of the circle and the path exceeds the specified circle radius.While this offers a straight-forward method to test for the existence of a solution, there is, in contrast to operation A, no simple fallback, which can be applied for arbitrary controllers, which rely on this path operation. Therefore, a reliable fallback solution, which ensures that the vehicle is approaching the path, has to be design including the specific control law. For many controllers including the famous pure-pursuit controller [41], the solution of the shortest-distance-problem (see operation C) is applicable as a fallback solution.

Point Projection Onto the Reference Path
Point projection is a well investigated topic, but still an ongoing research field in geometry (see, for example, [46][47][48][49]). Although for some path representations (e.g., if the path consists of circular arcs) an analytic solution exists, most implementations apply iterative numeric methods, similar to path operation A, to compute approximations of the solution. The existence of a solution is not ensured. A widely used fallback for tracking controllers is to transition to the shortest-distance-problem. A solution to this fallback problem always exists and if a solution to the point projection problem exists, the solutions are equivalent. The ambiguity of the solution can be handled based on the path direction (choosing the solution which gains the most progress along the reference path).

Summary of Interface Requirements from Tracking Control Perspective
The comprehensive investigations of the last sections provide the theoretical backbone in order to state the general requirements for a generic planning and control interface from control side. The central idea for the interface implementation is to detach the tracking error computation from the control component. On the one hand, this avoids redundant computations in different control components. On the other hand, it enables careful coordination with respect to the representation of the provided reference path. This supports the performance of the overall system, which is especially of interest in safety critical applications like collision avoidance. According to Section 3, the definition of three classifiers (vehicle reference point, look-ahead and error orientation) is sufficient to define the lateral tracking error definition applied in state-of-the-art path tracking controllers. Furthermore, according to Section 4, three elementary path operations are sufficient to compute all possible tracking errors, which can be defined based on the introduced tracking error classifiers. Hence, these elementary path operations can be implemented with respect to the reference path representation outside of the actual path tracking component, in order to supply various different tracking controllers with the required tracking error, as illustrated in Figure 8.

Path tracking
Tracking error

Reference path
Tracking error definition Path operations (Table 3) Reference path representation Vehicle pose Interface Figure 8. Interface concept to meet the output requirements defined by the state-of-the-art in path tracking controller design.
In order to complete the interface concept, the following section consider the path planning problem in general and the interface requirements resulting from the state-of-theart in path planning.

Interface Requirements from Path Planning Perspective
Similar to path tracking path planning, is a sub-problem of the more general trajectory planning problem. It focuses exclusively on the spatial planning, also known as lateral planning, neglecting the temporal aspect of the motion planning. The general limitations of the applicability of such a decoupled motion planning and control have already been mentioned in the Section 2. In addition, from planning perspective also limitations of this approach with respect to complex dynamic environments arise. However, this separation enables simplified planning for relevant use-cases like valet parking. The general path planning problem can be stated as follows: The planner has to compute a collision-free path from a given starting pose to a given final pose, complying constraints with respect to drivability (limited actuation systems, like a vehicle's bounded steering angle), comfort (bounded lateral acceleration and jerk), efficiency (length of the path and necessary actuation effort) and safety (distance to obstacles). Many surveys on different path planning approaches and algorithms have been published (see, for example, [2,5,[50][51][52]).
In contrast to the state-of-the-art path tracking controllers, where it was necessary to establish a reasonable generalization of the input requirements via a careful study of state-of-the-art components, the generalization of the output requirements of path planning components is more straight forward and does not need an extensive consideration of specific state-of-the-art path planning algorithms. On a qualitative level, there are two different output formats provided by path planning systems: Hermite path data and analytic curve expressions.
Hermite path data consist of a set of consecutive way points (position x, y ↦ G0 Hermite data) and optional higher-order geometric information: tangent (position x, y + orientation ψ ↦ G1 Hermite data), curvature (position x, ys + orientation ψ + curvature κ: ↦ G2 Hermite data (cf. Figure 9)) and so on. Hermite path data give a hint about the qualitative course of a continuous path, assuming that the single samples do not skip a significant section of the path. Alternatively a path planning algorithm may provide the reference path in form of an analytic curve expression. The most commonly used analytic curve expressions are parametric curves. In Appendix A, an overview on the basics of parametric curves and commonly used parametric curves expressions in path planning are given.
The more accurate the shape of a single analytic curve shall be specified, the more complex representations (e.g., high-order polynomials) are required. In practice, this yields an increased computational complexity and corresponding numerical issues. Hence, it is far more practicable to represent the planned path not as one single analytic curve but as a sequence of aligned curve segments, in which each are defined by simple analytic curves, yielding a so-called spline. The application of a segmented path needs an adaption of the elementary path operations stated in Section 4. The determination of a tracking control error has to be managed in two stages:

1.
Global: Identification for the respective path segment.

2.
Local: Application of the actual error computation within the path segment (see Section 4).
The identification of the respective path segment can inflate to a complex issue, since the actual optimal solution of this task requires the application of the path operation (step 2) on each path segment. In order to reduce the computational effort for step 1, a practicable workaround is to aim for a sub-optimal solution. Such a solution can be obtained, for example by applying the path operation to a simplified version of the path, like for example a linear interpolation of the way point within the path segments. However, the discrepancy between the sub-optimal solution and the optimal one, may become significant especially for reference paths including sharp turns, loops or cusps.
In summary, the path representations provided by state-of-the-art path planning algorithms feature a huge diversity. There is no obvious link for a potential generalization similar to the error classification for path tracking. However, according to Section 5, the implementation of identified elementary path operations depends on the reference path representation. Therefore, it is reasonable to include an internal reference path representation into the interface, which, in general, may differ from a possible parametric path provided by the planner. Since it is straight forward to generate Hermite path data from a given parametric path, by path sampling, the generalized input format is defined as Hermite path data. The drawback of this definition is that the proposed interface may withdraw analytic curve expressions potentially provided by high-sophisticated planning components.
The choice for an internal path representation is a degree of freedom in the interface design. Appendix A gives important hints for the pros and cons of different curves. A common choice are polynomial splines. Such splines may be defined in different polynomial bases (e.g., monomial and Bernstein basis). The missing step to finalizing the wanted generic motion planning and control interface is the parametrization of the internal path with respect to given Hermite way point data. This is covered by the well investigate research field of interpolation. For sake of completeness, Appendix B surveys some stateof-the-art algorithms for the interpolation of Bezier splines, which serve as internal path representation for the exemplary implementation of the interface (cf. Section 8). Figure 10 illustrates the intermediate result with respect to the input structure of the proposed generic interface.

Path planning
Hermite data

Internal path Interpolation
Interpolation algorithms (Appendix B) Internal path representation Interface Figure 10. Interface concept to meet the input requirements defined by state-of-the-art reference path representations.

A Generic Path Planning and Tracking Interface
Combining the above considerations from path planning and path tracking side, the concept for the generic interface design shall now be summarized (see Figure 11). The three major steps in the implementation of such an interface are: • Decision for an internal path representation. • Implementation of corresponding Hermite waypoint data interpolation algorithms (see Appendix B), in order to accomplish input (planning) modularity with respect to different data types (G0, G1, ⋯). • Implementation of corresponding error computation, based on the path operations discussed in Section 4 (path-line intersection, path-circle intersection and point projection), in order to accomplish output modularity (control).
The key design decision is the choice of an internal path representation. The internal path representation, on the one hand, has to be able to accurately describe a planned reference path. On the other hand the computational aspects of the required interpolation and path operation algorithms have to be considered. It is an important fact that this design decision impacts the final performance of the motion planning and control system, in terms of tracking performance (cf. Section 8) and computational effort.

Path planning
Error computation (  (Table 3) Internal path representation Vehicle pose Interface Figure 11. Interface for modular motion planning and control systems.
Such an interface is able to connect state-of-the-art path planning algorithms, which provide Hermite waypoint data, with state-of-the-art path tracking controller, which requires a lateral tracking error definition that is covered by the introduced error classifiers: vehicle reference, look-ahead and error orientation. Consequently, it enables the combination of a huge range of planning or tracking components without necessary interface modifications, which offers significant benefits in both simulation and operation: • In simulation, it supports a straight-forward identification of an appropriate component set, based on iterative combination, simulation and evaluation, considering specific scenarios and corresponding KPIs. This is an important aspect of ODD-based AD function assembly. Furthermore, a specific error definition can be applied as common evaluation measure for a set of tracking controllers, which could not be compared on a quantitatively based on their different native error definition on a fair basis (cf. the example in Section 8).

•
In operation, it enables the simultaneous execution of different software components as well as switching between different components. This on the one hand supports the design of AD-functions, for a set of varying ODDs extending the application range of Level 4 driving functions. On the other hand, it supports the application of redundant and fail-operational software in order to increase safety of an AD function.
In addition to these major benefits in simulation and operation, the application of the proposed interface offers additional possibilities in the AD function development. The resolution of the component interdependencies, which might impact the overall system performance, is a significant advantage in safety critical applications, like collision avoidance. Furthermore, as already mentioned in Sections 2 and 3.4, the tracking error computation can be executed also on a set of vehicle poses, generated by some motion prediction in order to support, e.g., MPC-based path tracking approaches. However, there might occur cases, which exclude the possibility of outsourcing the error computation to an interface component for some algorithmic reasons. In this case, the proposed interface still can operate as a reference path pre-processing unit, which may provide reference path sections of fixed quality, with respect to configurable requirements, e.g., equidistant sampling and path continuity, without any modifications of the planning components. Finally, the application of specific error definitions based on the current and predicted vehicle poses are also applicable and beneficial as risk indicators in threat and risk assessment (see for example [53,54]).

Exemplary Interface Application
In this final section, some of the aforementioned benefits and aspects of a generic interface shall be demonstrated in a practical use case. Starting point is a simplified but exemplary ODD-based AD function assembly problem. A path tracking controller shall be selected for application in an AD function for highway driving. This ODD arises a considerable number of specific scenarios. This example is restricted to an exemplary lanechange maneuver. Therefore, a standardized maneuver-the second half of a standardized double lane-change maneuver in [31]-is considered. The maneuver is performed at a constant speed of v = 72 km/h. Since no obstacles have to be considered in this maneuver a simple path planner is used. It uses cubic Bezier splines (cf. Appendix A) to plan a smooth trajectory within the defined maneuver corridor. The planned path is provided to the generic interface as G2 Hermite data, with a sample distance of 5 m. In order to show the impact of the internal path representation on the control performance, two different interface implementations are applied in simulation. The first one uses a simple linear path representation. The provided Hermite path data are interpolated linearly, resulting in piece-wise straight sections, respectively piece-wise linear orientation and curvature. Note that the linear interpolation of orientation and curvature do not represent the actual orientation and curvature of the resulting polygonal path, which would be piecewise constant respectively zero, but serves as an improved approximation. The second interface implementation is based on piece-wise polynomial path sections an applies the interpolation algorithms described in Appendix B. The G2 Hermite waypoint data are interpolated with quintic Bezier splines in order to achieve a G2 continuous internal reference path.
An exemplary set of two state-of-the-art path tracking controllers is used with a fixed parametrization (see Tables 5 and 6), including the applied lateral tracking error definition according to the proposed classification in Section 3: • Stanley ( [25]): • PurePursuit ( [41]): The two controllers shall just serve as an exemplary set of components for this demonstration. The performed evaluation can be extended straight forwardly for example to the entire set of tracking controllers listed in Table 2.
In order to compare the performance of different controllers, which, in general, apply different error definition, an additional lateral tracking error definition (vehicle reference: center of gravity, look-ahead: no, error orientation: heading) is used to provide a comparable error measure. The path planning system, the two exemplary interface implementations as well as the exemplary tracking controllers have been implemented in a Python-based software framework. This framework has been used to perform the simulations, which are discussed within the following section.  Figure 12 shows the results of a series of four simulations (all combinations of the two controllers and the two interfaces implementations). According to the top plots, both controllers in principle accomplish the required scenarios task and keep the vehicle inside the defined scenario corridor. Due to its look-ahead the lateral error of the PurePursuit controller increase earlier, resulting in an earlier initiation of the lane-change maneuver. Furthermore, this yields a more smooth maneuver with reduced steering effort due to the damping behavior of a look-ahead in path tracking (cf. Section 3.2 and [23]). The drawback of this property is the curve-cutting behavior of the final vehicle motion, which brings the vehicle to the borders of the scenario corridor several times. Considering the defined common error measure, this fact substantiates in a considerable ≈ 1 m) lateral offset of the vehicle's center of gravity with respect to the reference path. From this point of view, the Stanley controller shows superior tracking performance to the cost of an increased steering effort.
The comparison of the two different applied interfaces reveals the important fact that the internal path representation impacts the final tracking performance. The non-smooth linear reference path yields a non-smooth tracking error. The damping characteristic of the PurePursuit's look-ahead still ensures a satisfying steering command, which is almost equivalent to the corresponding steering command when applying the polynomial internal path. Contrary, the Stanley controller is affected through-out by this effect, yielding an unsatisfying jerky steering command. This consideration shows that in absence of an interface the Stanley controller is not applicable at all in this scenario in combination with the used planning system. Obviously, this is an illustrative edge-case example and the effect may be reduced when using a more dense sampling of the reference path, but, in general, this might be a fixed parameter of the planning system. The slight steering into the opposite direction of the Stanley controller results from an undesired property of the applied path interpolation algorithm, the so-called Runge's phenomenon.
In order to conclude this exemplary evaluation, based on the defined error measure lateral offset of the vehicle's center of gravity, the Stanley controller has to be favored in this scenario.  Simulation results: Lane-change maneuver [31] performed with two different path tracking controllers (Stanley [25] and PurePursuit [41]) using two different interface implementations (linear, respectively 5th order polynomial internal path representation). The plots on the top show the vehicle position, the plots in the middle illustrate the occurring lateral tracking errors (controller specific lateral tracking error + common error measure) and the bottom plots show the resulting steering commands computed by the two controllers.

Conclusions
Level 4 autonomous driving requires AD-functions, which are carefully matched to the specific ODD. The scientific state-of-the-art provides a tremendous amount of dedicated algorithms, which may be applicable for specific tasks of an AD-function in different ODDs. Hence, contrary to developing AD-functions from scratch for each ODD, it is beneficial to aim for a modular system architecture with generic interfaces, enabling fast combination and evaluation of sets of algorithms, without any code adaptions. This publication is dedicated to the design of such a generic interface between a local path planning and path tracking system. In order to ensure modularity with respect to different state-of-the-art path tracking controller, it contributes a classification of controllers based on the applied lateral tracking error definitions. Based on this classification the actual requirements from control side in the error computation are identified in terms of elementary path operations. This substantiates the advantage of including an internal reference path representation into the interface in order to resolve the interdependencies between the path planning and the path tracking system and, hence, to achieve the required input modularity (on planning side) and output modularity (on control side). With these building blocks, the publication contributes a generic interface concept and a solid theoretical basis for occurring design decisions in the implementation. Two exemplary implementations are finally applied in a demonstrative ODD-based AD assembly task. The application of such an interface offers significant advantages in simulation, like straight-forward combination, evaluation, and benchmarking of set of components in different scenarios, as well as in operation, as a key element for fail-operational and ODD-adaptive AD-function design. A concluding overview on the technical content of the publication is represented in Table 7. Table 7. Overview on the proposed generic interface concept for path planning and tracking.

Approach
• Analysis of requirements based on state-of-the-art components • Identification of potentials for generalization • Definition of component independent interface tasks and requirements

Concept
• Interface internal continuous reference path representation (Section 6) • Generalization of tracking error definition based on classifiers ((11) and Section 3) • Implementation of elementary path operations (Table 3)

Conflicts of Interest:
The authors declare no conflict of interest.

Appendix A. Parametric Path
This section gives a theoretical basis on parametric path representation and exemplary concepts.
Appendix A.1. Basics Analytic curve expressions can be given in terms of a implicit, explicit or parametric expression: In general, a parametric expression is most convenient, since it enables a global definition of arbitrary paths (from a starting point P a to a target point P b ), without any bijection issues as they occur for implicit and explicit expressions and which require path sectioning and transformation to local coordinate systems. The curve parameter τ is a monotonically increasing parameter, related to the progress along the path. It is a degree of freedom and can be used for normalization, or to achieve a path length parametrization τ = s (also known as natural, arc-length or chord-length parametrization): holds. x ′ and y ′ are the derivatives with respect to the curve parameter ∂x ∂τ and ∂y ∂τ . If the curve parameter in this case is interpreted as time (τ = t), the curve is passed with a speed of v = 1 m/s. Therefore, this parametrization is also called unit-speed parametrization (see for example [55]). Orientation and curvature of a parametric path compute as:

Appendix A.2. Clothoidal Path
A widely used curve in natural parametrization is the clothoid or Euler spiral. It is defined by a linear curvature with respect to arc length, and is widely used as transition curve between straight and circular road segments in road network design to offer a good steering behavior. Therefore, for it is an important parametric curve candidate for path planning (see, for example, [5,[56][57][58][59]). The consideration of clothoid x, y-coordinates by integration with respect to (A5) and (A6), x(s) = reveals the main drawback of a natural curve parametrization: Whereas arc length-based curve parameters (curvature, . . . ) feature a simple form, the functions for the coordinates may be transcendental functions (in this case Fresnel-Integrals), which cannot be solved analytically. This property of curves in natural parametrization complicates a coordinate-based definition, like curve fitting or interpolation, which is much more straight forward for other curve parametrizations. Therefore, several approaches have been published, aiming at approximation of clothoid section with other parametric curves (see, for example, [60][61][62]) to overcome this drawback while maintaining the advantage of a bounded path curvature.

Appendix A.3. Polynomial Path
A widely-used and, hence, important parametric path is the polynomial path. It is defined by a set of coefficients, with respect to some set of polynomial basis functions-monomial basis functions, in the most general case: Polynomials in monomial basis can be efficiently evaluated using Horner's scheme [63], which features a minimum number of additions and multiplications. Due to possibly huge differences in the range of the single polynomial coefficients, however, numerical instabilities might occur. The Bernstein basis is a widely used alternative to the monomial basis. For a polynomial of order n, the basis functions, τ T b,n = τ b,n,0 τ b,n,1 . . . τ b,n,n , (A12) compute as: where the relation n i=0 τ bn,i (τ) ≡ 1 and: τ ∈ (0, 1), holds. A polynomial curve in Bernstein basis is known as Bezier curve: The (n + 1) pairs of x, y-coefficients, the so-called control points, form a convex hull to the curve (see Figure A1) and, hence, offer a comprehensible geometric interpretation of the polynomial coefficients: Figure A1. Exemplary cubic Bezier curve from B 0 to B 3 controlled by control B 1 and B 2 .
Bezier curves play an important role in computer graphics, and also in path planning. With the De Casteljau's algorithm there exists a strong algorithm to evaluate a Bezier curve. It is not as efficient as the Horner's scheme but more numerically stable. As also the Bernstein basis finally consists of monomial terms, there exists a static transformation between these two bases: This transformation may be used to adaptively utilize the advantages of the different bases. Without proof the transformation matrix M n can be computed with the following Hadamard product: With a polynomial coefficient matrix Q n with switching signs with elements q i,j : and lower triangular pascal matrix extension to negative coefficients P L,−n , which is for example, for n = 3. This relation offers a simple approach to assemble a transformation matrix for specific order of the polynomials, which has not been published yet to the knowledge of the authors. In order to improve the quality of a polynomial approximations of specific curve sections, e.g., conic sections, while maintaining a low polynomial degree, there exists several generalizations (see, for example, [64]) like rational polynomial functions, B-splines and there combination: non-uniform rational B-splines (NURBS).

Appendix B. Hermite Data Interpolation
Path interpolation is an extensively researched topic and is considered as a special case of path smoothing (see [65]). In [65], a comprehensive overview on the state-of-the-art in path smoothing and interpolation is given. In [66], the mathematical properties of different interpolation functions are considered in very detail. This section shall not survey the complete state-of-the-art in path interpolation, but assemble basic definitions and a survey on interpolation algorithms for Bezier splines. The task of interpolation is to find a parametric curve expression for each path segment, which matches the given Gn Hermite data (see Figure A2), with n = 0, 1, ⋯. Figure A2. G2 Hermite data interpolation.
The number of matched geometric path information determine the minimal geometric continuity of the total path at the waypoints, i.e., the transition points between the single spline segments. If the path, furthermore, features continuous orientation (and curvature, . . . ) on the entire definition domain, the curve is called to have G1 (G2, . . . ) continuity. In contrast to this so-called geometric continuity, differential continuity refers to the derivatives of the curve with respect to the curve parameter τ. Differential continuity always implies geometric continuity. If the curve parameter τ is not applied also for longitudinal velocity planning, differential continuity is a too restrictive requirement, which does not provide any additional geometric features of the curve. However, in practice it is often more convenient to require differential continuity as it will be shown on a comprehensive example of a G2 Hermite interpolation with Bezier curves.
Consider a set of G2 Hermite way point data in two points P a and P b . This gives eight boundary conditions and, hence, a cubic Bezier spline (determined by four way points) should be sufficient to meet these conditions: x a , y a , θ a , κ a , x b , y b , θ b , κ b ↦ B 0 , B 1 , B 2 , B 3 , Due to non-linearity of tangent direction and curvature of a general parametric curve, the analysis of the existence and uniqueness of the solutions to this interpolation problem is rather complex. In fact, a cubic spline is not sufficient to interpolate arbitrary G2 Hermite data. Ref. [67] gives a proof that the necessary order for Hermite interpolation of arbitrary G2 data with a Bezier curves is 3 ≤ n ≤ 5 depending on the given boundary conditions for tangent directions and curvatures. In [68], conditions for the G2 boundary conditions on the existence and uniqueness of a cubic curve solution are given, restricting on shape preserving curves. In summary, the Hermite interpolation of arbitrary G2 data with Bezier curves of fixed order, in general, requires quintic curves. According to [67], this, consequently, means that occasionally up to 4 additional degrees of freedom occur.
An alternative approach is to implicitly solve the problem, requiring differential continuity (C2 for this example). This enlarges the original set of eight boundary conditions to twelve, and, consequently, directly requires a quintic Bezier curve (six control points). In [69,70], a parameter vector η has been proposed to utilize the additional degrees of freedom compared to the original problem for later curvature minimization. An extension of this concept for G3 Hermite interpolation has been published in [71,72]. A different common interpolation problem is that a specific geometric continuity between the single spline segments of a curve is required, but not (or not all of them) fixed to a given value. Following again an implicit approach over the differential continuity, a linear equation system can be set up to determine the coefficients of the curve segments. In order to obtain a fully determined equation system, additional global boundary conditions (initial conditions for the first segment and final conditions for the last segment) have to be specified. The necessary spline order n of the curve segments and the resulting number of additional global boundary conditions n BC can be determined straight forwardly considering Cx input data at N way points and required Cy path continuity (with x ≤ y): The evaluation of this identity in N (the spline order should be independent of the number of way points) yields: n BC = 2(y − x) and n = x + y + 1.
(A25) Table A1 lists the evaluation of (A25). These simple relations are quite useful in order to implement input data adaptive interpolation algorithm, but have not been published yet to the knowledge of the authors.
In the special case of x = 0 and y being an odd number and a homogeneous choice of the global boundary conditions, the resulting splines are called natural splines (see [66]). Such natural splines are characterized by the possibility to continuously extend them with polynomials of order n−1 2 outside of the nominal definition space, i.e., before the starting point P 0 respectively after the end point P N−1 .
While the splines, as proposed above, are simple to compute, they suffer from several drawbacks like an asymmetric shape in the case that the number of global boundary conditions is not a multiple of four. Furthermore, they are global splines, which means that appending additional way point data affects the entire spline. Another drawback of, in general, all polynomial approaches, is that, although a specific geometric or differential continuity is ensured at the spline transitions, there are, in general, no guarantees about the continuity within the single spline segments. In fact, for spline order n ≥ 3 cusps (curvature discontinuities) may occur. [73] gives necessary and sufficient conditions for the existence of such cusps. To handle this problem, special types of more restrictive polynomials, which result in so-called regular curves (curves without cusps) have been proposed. For example, in [74] Bezier spirals (a spiral is a curve with monotonic curvature, i.e., without interior curvature extrema) are used to ensure specific continuity. Table A1. Necessary spline order and number of free boundary conditions for given Hermite data and required differential path continuity.