Denis Claraz

Max J Friese

Hermann Von Hasseln

Ralph Mader

A dynamic Reference Architecture to achieve planned Determinism for Automotive Applications

With the evolution of modern cars towards more distributed architectures, considering also an increase of the data volume, we see the clear need of increased determinism in all types of communications: inter-tasks, inter-core, inter-partitions, inter-ecus. In parallel, to master the classical cost/quality/timeto-market tryptic, platform approaches are needed more than ever, to allow standardization. Our purpose in this document is to describe how to combine standardization and determinism, in the automotive domain, and what should be put in place in term of architecture and design patterns. Therefore, we describe our vision and experience of a dynamic reference architecture, as a "real-time framework" for easy development and integration of functions on one side, and for projects configuration on the other side. We explain the different levels of detail required by different users, the variability management required to support different classes of applications. Then, we introduce the need for determinism, and clarify what level of determinism we are talking about and which different approaches used can be used. In particular, we present a new approach that provides determinism not only at runtime, like Logical Execution Time (LET), but also throughout successive development cycles. In a next section, we present a deterministic reference architecture, that combines the two above mentioned objectives of standardization and determinism. We explain its main principles and the underlying constraints on the design of the functions. Following such an approach, we can achieve a certain degree of planned determinism (in opposition to an "inherited" one). Finally, we illustrate our proposal with practical cases taken from industrial projects, mostly from powertrain domain controllers.

I. INTRODUCTION

From their early days in basic engine control, powertrain electronics have evolved into sophisticated computers for precise combustion management, exhaust after-treatment and drivetrain control. Yet, that forty-year evolution pales in comparison to the transformation of the entire vehicle's electronics and software architecture over the coming decade. Over the years, new features for improved emission control, vehicle safety and comfort were incrementally introduced into the vehicle via new electronic control units (ECUs). The modern car now already contains as many as 150 ECUs which communicate with each other over in-vehicle networks such as CAN, Ethernet or FlexRay. This incremental expansion of the E/E landscape in a "distributed architecture" has, over the years, become the state of the art at most carmakers. As a result, the amount of software in the car continues to increase exponentially, with some estimates placing the number of lines of code in a premium car at over 700 million between 2025-2030, compared to an already massive 100 million lines of code in 2015. Architects imagine a simple E/E constellation borrowed from the IT-world as a "North Star": a few centralized servers for computation, and distributed smart actuators for real-time mechatronic control. However, most established car companies have a long legacy of car platforms which must be maintained in parallel with the desire to introduce new features via simple E/E architectures. A single leap from the current distributed architecture of as many as 150 ECUs, towards a server-based architecture centered around a handful of high-performance computers is done most often in intermediate steps, via domain (Powertrain, Chassis, Body, Interior) or and cross domain controllers, which we call master controller. [START_REF] Mader | The cars electronic architecture in motion: The coming transformation[END_REF] A. Repartitioning of Functions While cross-domain integration in a master controller, e.g. responsible for vehicle motion, reduces the number of ECUs in the car, it greatly increases the complexity of software inside the device. The master controller is not only the home of existing functions like energy management, torque management and vehicle stability functions, but also contains a slew of new functions to manage electrification, connectivity, and the impacts of autonomous driving. This E/E architectural trend affects the partitioning of the functionalities: They are divided in a low level sensing and actuation part and a high level computational part. The low level part will be still in a control device close to the corresponding sensors and actuators with hard real-time requirements, necessary for controlling a brush-less DC motor or a valve, just to mention some prominent examples. The algorithm part will move up to a higher architectural level in the E/E Architecture, like the Vehicle Motion Master Controller. The exchange of the sensor values, set point, etc. between low and high level ECUs will be realized with bus systems like CAN, CAN-FD and FlexRay.

B. Dynamic behaviour

Let us have a brief look on the architecture of automotive, especially powertrain, applications. They are typically based on an AUTOSAR Classic real-time operating system according to the OSEK standard. The configuration of the OS is done in a way that there are several recurring tasks with different periods from 1ms up to 1000ms which are distributed on several cores of a micro controller. These tasks call runnables subsequently according to the need of the data flow demanded by the causal chain of the function. As one can see in Fig. 1 the integration complexity with respect to the dynamic behavior of the system is different across various automotive applications. Typically the number of tasks and runnables increase with the size of the application and reaches its maximum for master-controller, battery management and engine-management-systems. When distributing functions of these applications over multiple ECUs one needs to carefully consider the timing behaviour of the event chains of the controlled system. Fig. 2 illustrates the basic principle of a distributed functionality with an ECU 1, responsible for reading the sensor values and transmitting them via CAN to the Master-Controller. The higher level algorithmic portion located in the Master Controller will receive the sensor values and use this input to compute a setpoint for the actuator controlled by a transmission-or engine-controller, called ECU2. The setpoint Fig. 2. Schematic of a control flow from a sensing ECU1 via the Master Controller to the acting ECU2, connected via CAN is transmitted via CAN to the acting ECU which will use this to apply the latest setpoint value to the actuator. The timing between reading the sensor value and applying the setpoint for the actuator must fulfill the requirements of the overall function which needs to be realized in the timing constraints given by the physics or the mechanics.

C. System integration and validation

These distributed functions will be developed by independent teams, working on software for the different ECUs with different update and release cycles. From one release to another the desire of the System Integrators is to have a control on the changes and best be able to reduce the systems test cases to a minimum while still guaranteeing the correct functional behaviour and a safe operation of the system. Therefore mechanisms are needed which implement a deterministic behaviour to reduce the necessary tests for the validation and enable the release of subsystems. In the following chapters we will manly focus on mechanisms which can be applied for a single device in the communication network to ease integration in the more complex devices like master controller or engine management systems, which are typically based on multi core controllers supporting different safety partitions.

II. DETERMINISM

The software technologies used in this context need to support this deterministic behaviour for static and dynamic aspects of the software system architecture. In the last years AUTOSAR Classic platform has been enriched in this direction. For the control of freedom from interference (FFI) safety partitions have been introduced in the AUTOSAR Classic standard. More recently, the release 20-11 [2] introduced the so called software clusters (SWCL) as independent development and build units with a defined interface layer: the software cluster connect to the rest of the system. This allows the development, validation and update of one software cluster, independently from the rest of the system. From a static architectural point of view the development and release of subsystems is covered by these approaches. Concerning the real-time behaviour of the system, an independence of the clusters needs also to be ensured: the update of a cluster should not impact the dynamic behavior of the others. This concerns not only the task behavior itself, but also the data communication between the clusters. In addition, different core to cluster mappings are considered: 1:1, 1:n, m:1, m:n, as shown in Fig. 3 Fig.

Actual distribution of Clusters on Cores

A. What is determinism in the dynamic behaviour

In such distributed context, our main interest is the inter-task data communication, when a data is transmitted or received (written, read). In case of multi-core architecture, we want to avoid 2 types of problems: concurrent accesses to the same data (consistency), and unstable data age (determinism).

The first problem happens when the two competing tasks attempt "simultaneously" to write (on one side), and read (or write, on the other side) the same data or data set. This "data consistency" issue (in the sense of stability and coherency) is solved by a buffering strategy, similar to AUTOSAR RTE/IOC [START_REF] Claraz | Introducing multi-core at automotive engine systems[END_REF] [4], and is not in the focus of this paper.

The second problem happens when the relative positions of the tasks jitters over the time, generating an instability of the number of writes between two successive reads, or viceversa. For instance, in Fig. 4, the 2 communicating tasks have a same period of 5ms, and also a deadline of 5ms: They can execute anywhere inside the shaded area (within the period), depending on the local situation on CPU load, interrupts, blocking semaphores, other tasks running, etc... Therefore their relative order is not guaranteed, and by consequence, the actuator function (blue task) may respond with an unstable delay to an input signal variation (yellow task): This "non-deterministic" data age can be solved by applying different scheduling and inter-task communication strategies, that will be detailed in the next chapter. As shown here, our main goal is to remove this uncertainty on the tasks communication paths, i.e. to ensure a correct sequence of causal chains.

As added benefits of deterministic communication, we can mention 2 aspects:

• Possibility to parallelize independent parts of algorithms, setting "rendez-vous" where data communication happens before the next parallel slot (chains of "fork join" patterns.) [START_REF] Mader | Design pattern in automotive multi-core embedded realtime environment and their support by scheduling strategies[END_REF]. In particular, the Logical Execution Time paradigm (LET, see II-B3) has been foreseen as a mean to enable multi-core introduction in automotive systems already in 2016 [START_REF] Hennig | Poster abstract: Towards parallelizing legacy embedded control software using the LET programming paradigm[END_REF] and in 2018 [START_REF] Biondi | Achieving predictable multicore execution of automotive applications using the LET paradigm[END_REF]. Furthermore, it was introduced in AUTOSAR Timing Extension [START_REF]Specification of timing extensions[END_REF] in 2020. • Mean to set time-budgets to tasks and to increase the decoupling between parts of the SW: as long as a task stays within his pre-defined time-interval, there is no impact on the other ones.

In our case (AUTOSAR OS, online scheduling), deterministic scheduling is not used to control the worst case execution time (WCET) of the task (avoiding concurrent access to shared resources like busses, memory, peripherals, . . . ), like required in offline scheduling strategies.

Finally, there can be different points of view on determinism, and on implementation level, independently of the chosen strategy, an uncertainty remains at what absolute point in time a given data is transmitted or received.

B. Different implementation strategies

In this paragraph, we describe different implementations of determinism, that may fit to the requirement, depending on the needed precision. These strategies (applied on successive projects, as described in section V) are:

1) Strategy 1: Short deadlines (Fig. 5): A basic and simple determinism can be reached by setting Task deadlines, periods, and offsets in a way that the communicating tasks will never overlap. For instance, 2 Tasks of period 5ms on different Cores can have a deterministic communication if they have a short deadline (e.g. DL=2ms) and an offset (e.g. O=2.5ms) between them. Their execution domains (shaded areas) do not overlap each other, and therefore an order is guaranteed. One has just to ensure that each Task fits to its timing requirements, by setting the appropriate system configuration (priority, . . . ). In the overall schedule of the TD tasks, data communication of each task is done in a gap left empty before its next period starts. The deadline of a TD-task is therefore shorter than its period: At maximum, it is equal to its period minus a fixed gap reserved for the bi-directional communication. A periodic task is created to communicate the data for all TD tasks. Inside each TD task, local buffers are used (similar to AUTOSAR implicit communication), instead of directly reading the global data. Each communication task publishes the buffers of the preceding TD task into the global data ("Terminate"), and copies the global data into local buffers of the succeeding TD task ("Release"). Therefore, the real position of the task within its deadline does not matter. What matters is the position of the communication gaps vs. each other. With such principle, the jitters of the 2 functional tasks have no impact on the data age, as long as they finish before the communication task: a data computed in the cycle N of a task will be available for the other task in the cycle N+1. 3) Strategy 3: Logical Execution Time (LET) paradigm (Fig. 7):

In the LET paradigm [START_REF] Kirsch | The logical execution time paradigm[END_REF], tasks execute anywhere within their designed time-interval (like in previous strategies), and the communication between them is done at the limits of the interval, using dedicated tasks (called "Release" and "Terminate"). The real determinism of the communication depends on how precise is the execution of these communication tasks. In the LET theory, the communication is done at each interval border, in a "zero time". But in the real implementation, the runtime for the data communication needs to be considered, and it must be ensured that the communication is done at the limits of -but inside -the interval. This constraint requires a careful planning of the intervals: For instance, enough margin needs to be reserved in the interval for the task (considering its WCET), but also for the communication (release + terminate) [10] [START_REF] Alfranseder | Logical execution time in the automotive environment[END_REF]. Also, conflicts (overlaps) between releases and terminates of different intervals shall be avoided, as they may end-up in conflicting accesses to the same data, with the resulting loss of determinism and coherency. TD and LET principles are very similar: In both cases, dedicated tasks are in charge of the inter-task communication. In both cases, an interval is defined for each functional task, which represents the time slot inside which the task is allowed to execute. In TD, the intervals are in practice nearly equal to the periods, whereas it should not be necessarily so. In LET, the intervals are much shorter than the period, and several intervals are set for the same period, whereas it should not be necessarily so. In TD, the actual communication of the data is done outside of the task frame, when the next (periodic) communication tasks executes. In LET, the actual communication of the data is done at the limit (inside) the interval.

4) Strategy 4: Planned LET (Fig. 8): The objective of this strategy is to ensure determinism of the communication between different tasks of different clusters. It also ensures a stability of this communication along the project development cycle, despite the successive upgrades: the communication between clusters is kept as planned. This strategy is in use in our newest program, which is described further in the chapter V.

C. For which data?

As seen in the previous paragraph, our motivation for determinism is the removal of the uncertainty of the data communication path between tasks, due to task jitters. Achieving a fixed age is a clear advantage of such scheduling, like LET, but there is a price to pay: First, the CPU utilization is not as optimized as it could be in a conventional system; Then, the duration of the Release/Terminate at the limits of the LET interval may become significant in proportion to the interval duration, in case of big data flows. Therefore, there is a need of a selective approach, where determinism is applied only on a subset of critical data. For the other data, classical data integrity (e.g. stability, or coherency) approach is sufficient, and more optimized. For instance, the LET approach could be limited to safety critical data, or for signal flows where the instability has system impact. Typically, it may depend also on the nature of the data. Control data (booleans, state machines, indexes, counters, ...) may have a stronger negative impact on the functional behavior in case of non-determinism, than more "continuous" data, which have low gradients. Finally, this is the consumer function of the signal, which knows better, whether a non-deterministic behavior of its inputs may have or not a negative effect on the strategy. In the case of Xcc communication, the objective is rather to concentrate the communication flow between the clusters in a few a-priori and stable defined channels, to reduce the impacts of upgrading one cluster. The challenge is here to properly map the exchanged data on the right Xcc communication tasks. On the consumer-cluster side, the different intervals and frequencies where the imported data is used have to be considered, together with the availability and location of XccIn Tasks. The idea is to have one single point of import, even if there are several consuming tasks/frequencies. On the producer-cluster side, a similar approach has to be followed, and finally the flow cross clusters has to be designed on overall system level, ensuring a coherency of the communication channels between the clusters. For sure, such an approach is easier when the clusters are decoupled, and exchange few information. In case of highly coupled clusters with several hundreds of interfaces, the a priori definition of all communication channels seems impossible, and in this case, a mixture between top-down & bottom-up approaches need to be applied.

III. REFERENCE ARCHITECTURE

Objectives of a reference architecture:

To facilitate the SW reuse, it is necessary that the reusable components and the reusing projects are developed according to a common framework. This framework comprises many facets, like a functional partitioning, a layered architecture, design patterns, coding rules, and more. One particular facet of this framework is a dynamic reference architecture, that ensures a correct real-time behaviour of the functions and projects.

Technical content: This reference architecture defines standard events, operating system tasks, as well as some transverse configuration items. Events are abstract artifacts that define timing properties like periods, deadlines, activation pattern (sporadic, periodic, aperiodic, ...), available phases (abstract way of specifying a sequence constraint [START_REF] Claraz | Deterministic Execution Sequence in Component Based Multi-Contributor Powertrain Control Systems[END_REF]), the behavior in case of system (core synchronous) transition [START_REF] Alfranseder | An efficient partitioning strategy for runnables in weakly dependent tasks on embedded multi-core systems[END_REF] [5], and other behavioral details. Tasks are concrete artifacts that define not only the basic OS configuration (core, priority, multi-activation, use of cooperative resource, . . . ), but also extensions like chaining to other tasks (if any), detailed LET configuration, memory section, asil level and more implementation details. Tasks are linked to events by a n:1 relationship, in the sense that n different tasks can implement the same event, while one event is implemented by at least one task. If different tasks implement the same event, then they comply individually and collectively to the event's constraints. For instance, if 2 tasks of the same event are chained, the complete chain fulfills the timing constraints of the event (in particular period & deadline).

In total, the complete definition of an event requires around 10 parameters, and even some more for a task (Fig. 9). Fig. 9. Parameters of events and operating system tasks. They are defined centrally in the reference architecture, to ensure a good synergy between functions and projects.

Functional content:

Functionally, the reference architecture contains different categories of events and related tasks:

• Angle based events and tasks are necessary for engine control applications, which have the most complex architectures. We can find here events of different periods (top dead center, engine rotation, camshaft rotations, ...), different phasing (different angular phases vs. top dead center). These events can be periodic or aperiodic, in all cases depending on the engine rotation speed. There are also engine related transitions, like engine stalling or cranking events, which require specific function initialization. • Time based events and tasks are ranging from 1ms to 1000ms. For some of them, different deadlines are provided. For instance, most of 10ms calculations use a 10ms deadline, but for some other, a short deadline of e.g. 3ms is necessary. For this, different events, and different sets of tasks are provided in the reference. • Kernel events and tasks for the infrastructure / Basic Software (BSW), as well as some function dedicated tasks (communication, watchdog, safety, background, CPU load, etc...). These tasks are also part of the reference, but are in general not open for Application Software (ASW) integration. • Finally, initialization events and tasks are provided, that correspond to transitions between different ECU modes: reset, shutdown, entry or exit into RUN or POST-RUN modes, etc ... At the end, the complete reference for a four core engine control system contains 80 events & 200 tasks. How to use for functions: Function developers refer to standard events to specify the timing requirements (therefore integration constraints) of their functions. They cannot refer to standard tasks for the same, as it would tight them too much to a dedicated project configuration, and therefore reduce their re-usability. As mentioned above, if a project implements different tasks for the same event, any of these tasks is guaranteed to respect the timing constraints of the event. Therefore, the timing properties of a function will be respected in the project as long as it is integrated in a task implementing the specified event.

In particular, core allocation is not a requirement of the function. Eventually, an affinity versus a certain core property (availability of double precision FPU, lock-stepped core, ...) or versus other functionality ("be on the same core than ...") might be a valid requirement, but has to be used carefully as it might end-up in a non solvable situation.

Seen from function development perspective, the reference architecture provides sufficient information to allow the specification of the function's integration constraints. These constraints are precise enough to ensure a correct dynamic behaviour of the function, and abstract enough to comply with diverse integration project, based on different microcontrollers (therefore available cores), integrating different functions (thereof customer plugins), having different system configurations (hybrid vs. pure combustion engines vehicles, diesel vs. gasoline, engine control vs. domain controller,etc..), etc... How to use for projects: Considering the high number of tasks required (up to 200 on a 6 cores application), and the need of overall coherency, configuring such a project is a significant effort, even if it has just to select into a large library of existing tasks described in all implementation details. Therefore the reference architecture provides a series of architecture variants ("reference architecture projects"), which correspond to our main use cases, like e.g. 3 & 4 cores engine management system, 3 cores transmission systems, or single core selective catalyst reduction system. The left pie-chart in Fig. 10 shows the percentage of projects using one or the other variant, over a selection of 70 projects in development. We see, for instance, that only 21% of the projects are not based on any variant, due to their atypical architecture.

In addition to the case-relevant event and tasks, each of these variants comprises transverse configurations, that can only be set at multi-task or multi-event level. This is the case, for instance, of sets of tasks that need to be enabled or disabled at once at given phases of the ECU life. Therefore, a project architecture is based (reuse by reference) on the variant, which is closest to its configuration. From this variant, the project can:

• reuse any artifact from the reference as is • ignore any artifact of the reference (not needed)

• adapt any artifact of the reference (deviation)

• create its own artifact w/o restriction. In any of these cases, the project is responsible to ensure that the timing requirements of the events are respected, for any of the underlying tasks.

Finally, the most usual case is that the project at Vitesco Technologies reuse one variant and all embedded artifacts with very few specializations, as shown in Fig. 10: Nearly 80% of all tasks used by our selection of projects are reused from the reference architecture without any modification.

IV. REFERENCE ARCHITECTURE FOR DETERMINISM

A. Reference Architecture for Time Determinism

The reference architecture described in the previous chapter is a living practice, and fits to a well-established product group such as combustion engine control. With the introduction of electrification and new domain-oriented architectures, where more determinism is required, this reference needs to be adapted. The new reference architecture will be simpler in the sense that there will be less complex events (related to engine rotation), but a simple timing event previously described by a period, offset and deadline, will now in addition be split into a series of LET intervals each one defined by an additional offset and a duration. The challenge is then to define a priori, w/o the full knowledge and background of potential user functions, a standardized organization of these intervals, that is kept stable over the development loops and across projects. This proceeding is contrary to most of the current LET projects, where the architecture has to be regularly readjusted to satisfy fast communication chains (a bottom-up approach where the architecture is adapted to the functions, and not vice-versa).

Below are listed some principles of this LET reference architecture, that we believe can satisfy our upcoming projects.

1) Distribution over the period: In order to balance the CPU load, the intervals are not "grouped" at the beginning of the period, but rather mostly equally distributed over the complete period. For instance in case of 5 intervals of 2ms length and 1000ms period, instead of concentrating them in a reduced slot of approximately 10 to 20ms, they are distributed over the complete 1000ms period. This principle provides flexibility in the later evolution of the architecture, as it gives space for moving or expanding existing intervals, or adding new ones, without reworking the complete scheduling.

2) Ratio interval length vs. WCET of task: We know that we need a minimum margin between the WCET of the task, and the length of its interval, to let enough time for interrupts, higher priority tasks, and for the release & terminate operations. But ensuring a minimum margin does not mean that this minimum value has to be applied: any longer interval is also valid. Therefore, the ratio between the interval length and the WCET of the task has to be above a minimum threshold, but does not have a maximum. Having a long interval, even if we know the WCET of the task will be much shorter is not an issue, and reduces the "stress" of the scheduling, by letting time for other tasks to execute. The important point here is that the position of data transfer, at the limits of the interval, is fixed, and in accordance with the communication needs between tasks. For sure, this ratio depends also on the number of intervals for the given period.

3) Minimum length of interval: A very fine granularity of intervals lengths requires a high resolution of the LET system, and therefore a high CPU load overhead. Finally, this concerns not only the lengths of the intervals, but also the offsets, and the periods.

4) Maximum number of intervals:

The number of intervals for a given period and core has to be limited. For instance, even on small periods like 100 or 1000ms, we limit ourselves to a reduced set of intervals, even if we could introduce a lot. The reason here is to limit the integration possibilities, keep the architecture relatively simple, and reduce the OS overhead.

5) Overlap between intervals of different periods:

In general, for a given core, the intervals are organized to avoid overlapping situations. Nevertheless, keeping this principle for all periods is particularly problematic when periods are quite different. For instance avoiding overlap between a 1000ms interval and a 5ms -even 1ms-interval introduces the high constraint that even for tasks of slow period, therefore relaxed deadlines, the interval length must be kept very short to avoid such overlaps. To avoid such constraints 3 groups of periods are defined, inside which no overlap can occur. On the opposite, cross different groups, an overlap is fully possible. Therefore, a 5ms interval will overlap a 1000ms interval. This is not contradicting the LET paradigm, and the communication between both tasks will be done at each intervals limits.

6) Core independence:

Having identical architectures on different cores have different advantages. First, it simplifies the overall architecture. Second, it allows the design of the functions independently of the core, providing an important flexibility at integration time. Another advantage is the possibility to implement "fork-join" patterns, where necessary. For this reason, we have designed a reference architecture with 2 types of clusters/cores: fast and slow clusters, to cover different use cases. But 2 fast (respectively slow) clusters have exactly the same architecture.

7) Cohabitation with non-LET tasks:

The LET architecture must reserve sufficient empty space for non LET tasks, from the kernel, or from non-deterministic application SW. This non-LET part of the SW usually has more relaxed timing constraints, and will get executed in the "holes" of the LET scheduling.

8) Constraints vs. Xcc tasks: For most of the periods, one XccIn and one XccOut are reserved, for inter-cluster communication. In some cases (fast frequencies), no cross cluster communication will be done. In some other (highly loaded frequencies), a double Xcc communication is planned, to allow the insertion of fast communication paths. By default the Xcc communication tasks are added at the begining (for XccIn) and at the end (XccOut) of the period ("chain of LET intervals").

As result of these principles, we defined a standard architecture, for which we give an abstract in Fig. 11. Each column represents a project. The green column gives the priority defined in the reference. A red cell indicates that the project deviates from the reference. A grey-shaded cell indicates that the task is not used. Fig. 11. A simplified LET-RA shown with two flavors: "Fast" and "Slow". Each flavor can be mapped onto a core, and be used to implement a Software-Cluster, or parts of a Software-Cluster. On the "Slow" flavor there are two sets of LET intervals with their own Xcc-tasks, which can be used for different functional causal chains. On the B0 cluster, Xcc "communication channels" (i.e. extra Xcc tasks) are inserted in the middle of the 10ms and 20ms chains, to satisfy some short causal chains. Note that this is a gross simplified picture.

B. Requirements for, and impact of RA on function design

As described in the next chapter 'Practical Example', the strategy up to now was in essence to adapt existing static and dynamic architectures to legacy functions and their software architecture. The drawbacks of such an approach have been outlined above, and a more planning is in need here. With the introduction of a Reference Architecture for Time Determinism it is clear that some restrictions and rules on the functions design level are necessary. This is by no means something new, as for example the Autosar component model also puts some constraints on the function design. For Time Determinism and the introduction of LET, which results in a component model for the dynamic aspects of the architecture, similar constraints needs to be formulated. As already stated, without the full knowledge of potential user functions, it is a real challenge to define the Reference Architecture. But, there is a lot of implicit information contained in legacy projects and from foreseeable development of user functions, which can be used to derive some minimal assumptions and constraints for function design.

Some fundamental basics of a function design include:

1) In the case of a periodic functions, the frequency with which these functions shall be called. It is helpful to avoid frequency dividers, because these would unnecessarily enlarge LET intervals and might lead to a waste of time resources. Although, to minimize complexity, it is also of importance to confine the number of task (or LET interval) periodicities. This is a tradeoff, and depends clearly of the kind of software project and user functions.

In our experience there is generally enough information available to decide for a set of periodicities. 2) In the case of event-triggered functions, the information on a worst case response time of a causal chain in which these functions are embedded is needed. If planned to embedd event-triggered functions into LET-intervals, it should be coordinated with the overall set of periodicities, and if over-or undersampling is appropriate. 3) In general, the embedding of functions in one or more causal chains, together with minimal latencies requirements these causal chain have to fulfil, 4) or, at least, the predecessor and successor relations of functions which define execution order constraints. 5) The description of the dependency of functions on other functions in order to build up a data dependency graph. Such data dependency graph are used to optimize implementations of causal chains or resolve concurrency issues on the LET-interval structure. The data dependency graphs is not only needed in order to verify requirements of causal chains in a Software-Cluster, or among Software-Clusters, but may also be necessary in cases where a Software-Cluster has to be mapped onto more than one core (parallelization). 6) A classification to which SW-Cluster functions are assigned to. 7) An estimate of the resource consumption of functions.

These include memory consumption, the the amount of data to be buffered for determinism (in or among SW-clusters: therefore a detailed analysis of the data dependency graphs are necessary, see ( 5)), estimates of (worst-case) execution times in order to map functions onto LET-intervals. It is also of crucial importance to have information on the volatility of the runtime of functions.

In most practical cases, static WCET analyzes are not feasible, but information on the functional content often helps to classify these functions. 8) There are also a number of non-functional requirements which have to be considered. Among them are a classification of functions according to ASIL-levels. This might lead to restrictions on the mapping fo ASIL-relevant functions to cores of multi-core controller which a have Lock-Step core behind. Another important restriction is the placement of functions related to signal mappings and network diagnostics (middleware), which should be placed with respect to the capability to distribute basic software functions onto cores. There is also an important restriction coming from the Autosar Software architecture: atomic Software components must be mapped onto one core, i.e., the runnables are not allowed to be dis-tributed among cores. This list has to be understood as a minimal set of user function properties, or properties of a given Software architecture. On the other hand, this list can be used as a minimal set of impact properties for the design of user function.

Depending on the Software architecture of user functions it might be appropriate to define several "flavors" of task structures of a Reference Architecure, which then can be used on different cores of a target multi-core controller. With this basic information at hand, the following required information can be gathered: 1) which "flavour" of the RA should be instantiated on each core of the target controller, 2) an analysis and mapping of functions onto tasks or LET intervals of a SW-Cluster (e.g., corresponding to existing dynamical concepts), to fulfil inter-SW-Cluster communication, 3) an analysis and placement of intra-Cluster-Communication (Xcc tasks), in order to fulfil causal chain requirements.

V. PRACTICAL EXAMPLE

In this section we give a brief history of how multi-core architectures have become part of the development for the central powertrain controller at Mercedes-Benz Cars. Following this, we discuss the demands of the upcoming generations and finally we give an outlook for future generations which provides additional motivation to pursue LET reference architectures.

In the following, we refer to five different generations of central powertrain controllers: Gen A (launched around 2012), Gen B (launched around 2016), Gen C0 (launched around 2020), Gen C1 (launched around 2020), and Gen D (to be launched around 2024).

A. Evolution of the Dynamic Architecture of the Central Powertrain Controller

The development of the dynamic architecture of the central powertrain controller has been influenced by multiple factors. Firstly, the hardware architecture has an impact as it determines the number of available cores and the communication between software allocated on these cores. Secondly, the software architecture plays an important role. A monolithic architecture (cf. [START_REF] Staron | Automotive Software Architectures[END_REF]) can not be freely distributed, wheres a component-based architecture with well-defined interfaces also gives more flexibility for the scheduling. It stands to reason that the amount of signals exchanged via the interfaces also impacts the scheduling and therefore the dynamic architecture. The more signals are communicated, the more scheduling constraints potentially exist. In Fig. 12 1) Gen A : This is the first generation taking the role of a domain controller. It was using a single-core controller with a multi-task system which was scheduled using a priority-based preemptive algorithm. For this, basic data consistency methods were introduced.

2) Gen B : In this generation, tasks are still scheduled using a priority-based preemptive scheduling. Since it is the first generation with a multi-core controller, in Gen B the first cautious utilization of multi-core was introduced. Tasks were distributed on the different cores with limited use of task chaining techniques. These techniques allow rule out any overlap of certain tasks across two cores. See also page 3 strategy 1.

3) Gen C0 : In Gen C0 the use of multi-core scheduling has been developed further. To cope with the arising challenges different mechanism for time determinism have been introduced. While still using the same priority-based preemptive scheduling, and mostly reusing existing OS-tasks from the previous generation, but implementing data determinism mechanism for tasks with fast periods. Although this is not strictly following the LET approach, it was the first time communication mechanisms following the LET semantics were implemented. Furthermore, synchronization of the clocks of some of the powertrain ECUs has been implemented to orchestrate network communication with other controllers within the domain. See also page 3 strategy 2.

4) Gen C1 : In this generation, time determinism was rolled out for almost all application-level tasks. For the first time a LET-based scheduling for the application software was used in this ECU to ensure for data determinism, enable load better balancing by parallelization, and implementation of causal chains by design. To achieve this, a detailed data dependency analysis for the design of causal chains was developed [START_REF] Hennig | Poster abstract: Towards parallelizing legacy embedded control software using the LET programming paradigm[END_REF]. See also page 4 strategy 3.

5) Gen D : With Gen D a cluster-concept is introduced allowing more flexible development. This also comes with more sophisticated methodologies for architectural work for both, the static software as well as the dynamic software architecture. On the static as well as on the dynamic side, architects are working with component models. While the static side architects can rely on the well-established AUTOSAR component model, for the dynamic side new concepts have been developed. More precisely, a reference architecture with SL-LET-like [START_REF] Gemlau | Efficient run-time environments for system-level LET programming[END_REF] is implemented on the dynamic side, which we call planned LET. The primary objective is to further improve stability of the development process during different phases of a project. See also page 4 strategy 4.

B. Future of the of the Central Powertrain Controller

As depicted in Fig. 12, the amount of signals communicated with fast frequencies steadily increases with every generation of the central powertrain controller. This is also expected to happen from Gen C to Gen D . In addition, the introduction of the cluster-concept allows to configure different configurations consisting of varying clusters. In the maximum configuration we expect an increased demand of deterministic communication by 25 to 30 percent compared to Gen C1 . A considerable share of this increases comes from the EV part in Gen C2 , however, it is also possible that more functionalities are integrated in new clusters.

VI. CONCLUSION AND OUTLOOK

In the paper we have shown the evolution of deterministic scheduling and data communication approaches of the past decade in the powertrain domain. From single core to multi core, from a project architecture to a reference architecture. We have shown how a reference architecture for the dynamic aspects of an embedded automotive system is applied in practice at Vitesco Technologies. The evolution of the central power-train controller at Mercedes-Benz Cars clearly shows the gradual establishment of LET-based data determinism mechanisms. Initially, the goal was to utilize multi-core architectures in a safe manner, With LET now being successfully implemented, we strive for an independent dynamic software architecture with LET frames as the components. Especially the application of a dynamic reference architecture in combination with the AUTOSAR Flexibility concept will enable an independent development and release of SW-clusters and so it will help to manage complex embedded automotive software systems. As a next step these approaches can be extended to in-vehicle networks in the sens of a System Level LET.

Fig. 1 .

 1 Fig. 1. Number of cores, tasks and runnables of different automotive applications

Fig. 4 .

 4 Fig. 4. Impact of Task jitter on determinism of flow, and response time of function

Fig. 5 .

 5 Fig. 5. Short deadline tasks with offsets ensure a deterministic flow2) Strategy 2: Time Determinism (TD) algorithm (Fig.6): In the overall schedule of the TD tasks, data communication of each task is done in a gap left empty before its next period starts. The deadline of a TD-task is therefore shorter than its period: At maximum, it is equal to its period minus a fixed gap reserved for the bi-directional communication. A periodic task is created to communicate the data for all TD tasks. Inside each TD task, local buffers are used (similar to AUTOSAR implicit communication), instead of directly reading the global data. Each communication task publishes the buffers of the preceding TD task into the global data ("Terminate"), and copies the global data into local buffers of the succeeding TD task ("Release"). Therefore, the real position of the task within its deadline does not matter. What matters is the position of the communication gaps vs. each other. With such principle, the jitters of the 2 functional tasks have no impact on the data age, as long as they finish before the communication task: a data computed in the cycle N of a task will be available for the other task in the cycle N+1.

Fig. 6 .

 6 Fig. 6. TD communication done in end of cycle task. A terminate (T) driver publishes the data (computed in the previous cycle) to the global memory, and a release (R) driver fetches the data from the global memory for the next cycle computations. This example shows clearly that the flow between the fast (yellow) task & the slow one (blue) is perfectly deterministic, independently of the jitters of the tasks in their respective intervals.

Fig. 7 .

 7 Fig. 7. LET communication: Different intervals/tasks on different cores. Communication is done at limits of each interval in the Release & Terminate drivers.

Fig. 8 .

 8 Fig. 8. Cross cluster communication: Clusters A & B communicate at pre-defined & fixed points (Xcc tasks), which are independent of the internal details of each cluster. The Xcc tasks are in charge of distributing (respectively collecting) the inter-cluster data to the different consuming (resp. producing) tasks inside the cluster. LET communication is applied for the internal flow of the cluster.

Fig. 10 .

 10 Fig. 10. Comparison of OS tasks priorities between a selection of 70 projects and the reference architecture. Each line represents a task from the reference. Each column represents a project. The green column gives the priority defined in the reference. A red cell indicates that the project deviates from the reference. A grey-shaded cell indicates that the task is not used.

Fig. 12 .

 12 Fig. 12. Signals Written with Frequency 5, 10, and 20ms in the ASW of different generations of the Central Powertrain Controller

  the increase in the amount of signals exchanged within the OEMs application software is depicted. More precisely, the figure shows signals exchanged with high frequencies between generations of the central powertrain. Please note, that Gen C1 is installed in electric vehicles (EV) and therefore has less signals as no combustion engine is controlled. Starting from Gen B , the determinism is used

		8,000
	# of signals written	2,000 4,000 6,000
		0
		0.005	0.01	0.02
			Frequency [s]
		Gen A Gen B Gen C1 Gen C2

The LET communication described above ensures determinism of communication between tasks at runtime. But in case of distinct clusters, each one with its own tasks, it cannot be ensured that the communication is still done at the same position, when one of the 2 clusters gets updated (e.g. reflashed). Even if the architectures (number of tasks, periods, offsets, lengths) of all clusters are frozen (which might not be the case), it is possible that in the new upgrade of cluster B (e.g. on core 3), the production of the inter-cluster data is moved from the 1st to the 2nd interval. Consequently, the behavior of the cluster A (on cores 1 & 2) would be affected by this modification of cluster B, if the tasks of the different clusters would directly communicate. Here, LET alone would bring a certain determinism at runtime, but would not offer any determinism over development cycles. To avoid this effect, cross-cluster communication tasks are created, that define communication channels between the clusters, and that are fixed on system design level, in term of position, and data to be transmitted. In other words, we have a component model for the dynamic aspects of the architecture. In the example Fig.8, we show that for cluster A distributed on 2 cores, that the (green) importing task ("XccIn") can even be implemented on a different core than the (red) exporting task ("XccOut").Finally, this concept has 2 additional benefits: First, it compensates one weakness of the LET paradigm: its single interval scope: With LET, each interval is treated as an own execution container, for which a high degree of data integrity is ensured (determinism, stability, coherency). But in reality, a complete system is based on several -or even many -intervals. and some of them consume the same information. Then, LET does not answer to the question of data integrity for a complete set of tasks. For instance, one might have the need that all intervals of same period (e.g. 10ms) share the same value for a data coming from another period (e.g. 10ms) or cluster. We might even need to define, in a series of successive intervals, which one should work with the latest value, while the others may work with an older information ("fast causal chain"). With Xcc communication, the producer cluster decides at which instant it communicates certain information to all consumers, and each consumer decides for itself at which instant it imports the information. There is a total decoupling between the actual computation/use of the data and its communication. As second side effect, the Xcc communication reduces the conversion overhead between the clusters, compared to a direct task-to-task communication: The import of a data from another cluster is done only once, even if this data is used in many tasks (intervals).


Solving Sparse Linear Inverse Problems: Analysis of Reweighted 1 and 2 Methods

David Wipf and Srikantan Nagarajan

Biomagnetic Imaging Laboratory University of California, San Francisco CA 94143 Email: {dwipf,sri}@mrsc.ucsf.edu

Abstract-A variety of practical methods have recently been introduced for finding maximally sparse representations from overcomplete dictionaries, a central computational task in compressed sensing and source localization applications as well as numerous others. Many of the underlying algorithms rely on iterative reweighting schemes that produce more focal estimates as optimization progresses. Two such variants are iterative reweighted 1 and 2 minimization; however, some properties related to convergence and sparse estimation, as well as possible generalizations, are still not clearly understood or fully exploited. In this paper, we make the distinction between separable and nonseparable iterative reweighting algorithms. The vast majority of existing methods are separable, meaning the weighting of a given coefficient at each iteration is only a function of that individual coefficient from the previous iteration (as opposed to dependency on all coefficients). We examine two such separable reweighting schemes: an 2 method from Chartand and Yin (2008) and an 1 approach from Candès et al. (2008), elaborating on convergence results and explicit connections between them. We then explore an interesting non-separable variant that can be implemented via either 2 or 1 reweighting and show several desirable properties relevant to sparse recovery. For the former, we show a direct connection with Chartrand and Yin's approach. For the latter, we demonstrate two desirable properties: (i) each iteration can only improve the sparsity and (ii), for any dictionary and sparsity profile, there will always exist cases where non-separable 1 reweighting improves over standard 1 minimization.

I. INTRODUCTION

In recent years, there has been considerable interest in finding sparse signal representations from redundant dictionaries [START_REF] Donoho | For most large underdetermined systems of linear equations the minimal 1 -norm solution is also the sparsest solution[END_REF], [START_REF] Donoho | Optimally sparse representation in general (nonorthogonal) dictionaries via 1 minimization[END_REF], [START_REF] Fuchs | On sparse representations in arbitrary redundant bases[END_REF], [START_REF] Gribonval | Sparse representations in unions of bases[END_REF], [START_REF] Tropp | Greed is good: Algorithmic results for sparse approximation[END_REF]. The canonical form of this problem is given by,

min x x 0 , s.t. y = Φx, (1)
where Φ ∈ R n×m is a matrix whose columns φ i represent an overcomplete or redundant basis (i.e., rank(Φ) = n and m > n), x ∈ R m is a vector of unknown coefficients to be learned, and y is the signal vector. The cost function being minimized represents the 0 (quasi)-norm of x (i.e., a count of the nonzero elements in x). If measurement noise or other complications are present, we instead solve the alternative problem

min x y -Φx 2 2 + λ x 0 , λ > 0, (2)
noting that in the limit as λ → 0, the two problems are equivalent (the limit must be taken outside of the minimization).

Unfortunately, an exhaustive search for the optimal representation requires the solution of up to m n linear systems of size n×n, a prohibitively expensive procedure for even modest values of m and n. Consequently, in practical situations there is a need for approximate methods that efficiently solve (1) or (2) with high probability. Many recent sparse approximation algorithms rely on iterative reweighting schemes that produce more focal estimates as optimization progresses [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF], [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF], [START_REF] Davies | Restricted isometry constants where p sparse recovery can fail for 0 < p ≤ 1[END_REF], [START_REF] Palmer | Variational EM algorithms for non-Gaussian latent variable models[END_REF], [START_REF] Rao | Subset selection in noise based on diversity measure minimization[END_REF]. Two such variants are iterative reweighted 2 and 1 minimization. For the former, at the (k + 1)-th iteration we must compute

x (k+1) → arg min x y -Φx 2 2 + λ i x 2 i w (k) i = W (k) Φ T λI + ΦW (k) Φ T -1 y, (3)
where W (k) is a diagonal weighting matrix1 from the k-th iteration with i-th diagonal element w

(k) i
that is potentially a function of all x (1) , . . . , x (k) . Similarly, the 1 reweighting variant solves

x (k+1) → arg min x y -Φx 2 2 + λ i |x i | w (k) i , (4)
although no analytic solution exists in this case and so a numerical program (e.g., interior point method) must be adopted. While this is typically an expensive computation, the number of iterations of (4) required is generally much less than (3) and, unlike (3), even a single iteration produces a very sparse solution. A second advantage of ( 4) is that it is often much easier to incorporate additional constraints, e.g., bounded activation or non-negativity of x [START_REF] Bruckstein | A non-negative and sparse enough solution of an underdetermined linear system of equations is unique[END_REF]. This is because few iterations are needed and the per-iteration computational complexity need not change significantly with the inclusion of many useful constraints. In contrast, with (3) we lose the advantage of closed-form updates on x when such constraints are imposed.

In both 2 and 1 reweighting schemes, different methods are distinguished by the choice of W (k) , which ultimately determines the surrogate cost function for promoting sparsity that is being minimized (although not all choices lead to convergence or sparsity). In this paper we will explore several different weighting selections, examining convergence issues, analytic properties related to sparsity, and connections between various algorithms. In particular, we will discuss a central dichotomy between what we will refer to as separable and non-separable choices for W (k) . By far the most common, separable reweighting implies that each w

(k) i is only a function of x (k)
i . This scenario is addressed in Section II where we examine the 2 method from Chartand and Yin (2008) [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] and an 1 approach from [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF] [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF], elaborating on convergence results and explicit connections between them. In contrast, the non-separable case means that each w (k) i is a function of all x (1) , . . . , x (k) , i.e., it is potentially dependent on all coefficients from all past iterations. Section III explores an interesting non-separable variant that can be implemented via either 2 or 1 reweighting and shows several desirable properties relevant to sparse recovery. For the former, we show a direct connection with Chartrand and Yin's approach. For the latter, we demonstrate two desirable properties: (i) each iteration can only improve the sparsity and (ii), for any dictionary and sparsity profile, there will always exist cases where non-separable 1 reweighting improves over standard 1 minimization. Simulations involving all of these methods are contained in Section IV.

II. SEPARABLE REWEIGHTING SCHEMES

Separable reweighting methods have been applied to sparse recovery problems both in the context of the 2 norm [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF], [START_REF] Figueiredo | Adaptive sparseness using Jeffreys prior[END_REF], [START_REF] Palmer | Variational EM algorithms for non-Gaussian latent variable models[END_REF], [START_REF] Rao | Subset selection in noise based on diversity measure minimization[END_REF] and, very recently, the 1 norm [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF]. All of these methods (at least locally) attempt to solve

min x y -Φx 2 2 + λ i g(|x i |), (5)
where g(•) is a non-decreasing function. In general, (virtually) any square-concave2 g(•) can be handled using reweighted 2 [START_REF] Palmer | Variational EM algorithms for non-Gaussian latent variable models[END_REF], while any concave g(•) can be used with reweighted 1 [START_REF] Fazel | Log-Det heuristic for matrix rank minimization with applications to Hankel and Euclidean distance matrices[END_REF]. Many of these methods have been analyzed extensively in the past; consequently we will briefly address outstanding issues pertaining to two new approaches with substantial promise.

A. 2 Reweighting Method of [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] In [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] the 2 reweighting

w (k+1) i → x (k+1) i 2 + (k+1) (6)
is proposed (among others that are shown empirically to be less successful as discussed below), where (k+1) ≥ 0 is a regularization factor that is reduced to zero as k becomes large. This procedure leads to state-of-the-art performance recovering sparse solutions in a series of empirical tests using a simple heuristic for updating (k+1) and assuming λ → 0 (noiseless case); however, some convergence issues are outstanding. Here we sketch a proof that this method will converge, for arbitrary sequences (k+1) → 0, to a local minimum of a close surrogate cost function to (1) (similar ideas apply to the more general case where λ is nonzero).

To begin, we note that there is a one-to-one correspondence between minima of (1) and minima of

min x i log |x i |, s.t. y = Φx, (7)
which follows since x 0 ≡ lim p→0 i |x i | p and lim p→0

1 p i (|x i | p -1) = i log |x i |.
The penalty function in [START_REF] Donoho | For most large underdetermined systems of linear equations the minimal 1 -norm solution is also the sparsest solution[END_REF] can be upper-bounded using

log |x i | ≤ 1 2 log |x 2 i + | ≤ x 2 i + 2γ i + 1 2 log γ i - 1 2 , (8)
where , γ i ≥ 0 are arbitrary. The second inequality, which follows directly from the concavity of the log function with respect to x 2 i , becomes an equality iff

γ i = x 2 i + . Now consider solving min x,γ, i x 2 i + γ i + log γ i , s.t. y = Φx, ≥ 0, γ i ≥ 0, ∀i, (9) where γ
[γ 1 , . . . , γ m ] T . Again, there is a one-to-one correspondence between local minima of the original problem (1) and local minima of [START_REF] Fazel | Log-Det heuristic for matrix rank minimization with applications to Hankel and Euclidean distance matrices[END_REF]. For fixed and γ, the optimal x satisfies x = ΓΦ T ΦΓΦ T -1 y, with Γ diag[γ] and, from above, the minimizing γ for fixed x and is γ i = x 2 i + , ∀i. By construction, coordinate descent over x, γ, and is guaranteed to reduce or leave unchanged (9) (the exact strategy for reducing is not crucial).

It can be shown that these updates, which are equivalent to Chartrand and Yin's 2 reweighting algorithm with w (k) i = γ i , are guaranteed to converge monotonically to a local minimum (or saddle point) of ( 9) by satisfying the conditions of the Global Convergence Theorem (see for example [START_REF] Zangwill | Nonlinear Programming: A Unified Approach[END_REF]). At any such solution, = 0 and we will also be at a local minimum (or saddle point) of [START_REF] Donoho | For most large underdetermined systems of linear equations the minimal 1 -norm solution is also the sparsest solution[END_REF]. In the unlikely event that a saddle point is reached (such solutions to [START_REF] Donoho | For most large underdetermined systems of linear equations the minimal 1 -norm solution is also the sparsest solution[END_REF] are very rare [START_REF] Rao | An affine scaling methodology for best basis selection[END_REF]), a small perturbation leads to a local minimum.

Of course obviously we could set → 0 in the very first iteration, which reproduces the FOCUSS algorithm and its attendant quadratic rate of convergence near a minimum [START_REF] Rao | An affine scaling methodology for best basis selection[END_REF]; however, compelling evidence from [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] suggests that slow reduction of is far more effective in avoiding suboptimal local minima troubles.

The weight update ( 6) is part of a wider class given by

w (k+1) i → x (k+1) i 2 + (k+1) 1-p 2 ( 10
)
where 0 ≤ p ≤ 2 is a used-defined parameter. With p = 0, we recover [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] and also obtain the best empirical performance solving (1) according to experiments in [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF]; other values for p lead to alternative implicit cost functions and convergence properties. Additionally, as brought to our attention by a reviewer, for a carefully chosen (k+1) update, interesting and detailed convergence results are possible using [START_REF] Figueiredo | Adaptive sparseness using Jeffreys prior[END_REF], particularly for the special case where p = 1 which produces a robust means of finding a minimum 1 norm solution using reweighted 2 [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF]. However, the selection for (k+1) used to obtain these results may be suboptimal in certain situations relative to other prescriptions for choosing p and (see Section IV-A below). 3 Regardless, the underlying analysis from [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] provides useful insights into reweighted 2 algorithms.

B. 1 Reweighting Method of [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF] [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF] An interesting example of separable iterative 1 reweighting is presented in [START_REF] Candès | Enhancing sparsity by reweighted 1 minimization[END_REF] where the selection

w (k+1) i → x (k+1) i + ( 11
)
is suggested. Here is generally chosen as a fixed, applicationdependent constant. In the noiseless case, it is demonstrated based on [START_REF] Fazel | Log-Det heuristic for matrix rank minimization with applications to Hankel and Euclidean distance matrices[END_REF] that this amounts to iteratively solving

min x i log (|x i | + ) , s.t. y = Φx. ( 12
)
The FOCUSS algorithm [START_REF] Rao | An affine scaling methodology for best basis selection[END_REF] can also be viewed as an iterative reweighted 2 method for locally solving [START_REF] Gribonval | Sparse representations in unions of bases[END_REF] for the special case when = 0; however, Candès et al. point out that just a few iterations of their method is far more effective in finding sparse solutions than FOCUSS. This occurs because, with = 0, the cost function [START_REF] Gribonval | Sparse representations in unions of bases[END_REF] has on the order of m n deep local minima and so convergence to a suboptimal one is highly likely. Here we present reweighted 2 updates for minimizing [START_REF] Gribonval | Sparse representations in unions of bases[END_REF] for arbitrary . Using results from [START_REF] Palmer | Variational EM algorithms for non-Gaussian latent variable models[END_REF], it is relatively straightforward to show that

log (|x i | + ) ≤ (13)
x 2 i γ i + log   2 + 2γ i 1 2 + 2   - 2 + 2γ i 1 2 - 2 4γ i for all , γ i ≥ 0 with equality iff γ i = 2(x 2 i + |x i |).
Note that this is a very different surrogate cost function than [START_REF] Donoho | Optimally sparse representation in general (nonorthogonal) dictionaries via 1 minimization[END_REF] and utilizes the concavity of log (|x i | + ), as opposed to log(x 2 i + ), with respect to x 2 i . Using coordinate descent as before with w

(k) i = γ i leads to the reweighted 2 iteration w (k+1) i → 2 x (k+1) i 2 + x (k+1) i , (14)
which will reduce (or leave unchanged) [START_REF] Gribonval | Sparse representations in unions of bases[END_REF] for arbitrary ≥ 0. In preliminary empirical tests, this method is superior to regular FOCUSS and could be used as an alternative to reweighted 1 if computational resources for computing 1 solutions are limited. Additionally, the most direct comparison between reweighted 1 and 2 in this context would involve empirical tests using [START_REF] Neal | Bayesian Learning for Neural Networks[END_REF] versus the method from Candès et al., a subject addressed in [START_REF]Iterative Reweighted 1 and 2 Methods for Finding Sparse Solutions[END_REF]. Also, it would be worthwhile to compare [START_REF] Neal | Bayesian Learning for Neural Networks[END_REF] using a decreasing update with (6) since both are derived from different implicit bounds on log |x i |.

III. NON-SEPARABLE REWEIGHTING SCHEMES

Non-separable selections for W (k) allow us to minimize cost functions based on general, non-separable sparsity penalties, meaning penalties that cannot be expressed as a summation over functions of the individual coefficients as in [START_REF] Davies | Restricted isometry constants where p sparse recovery can fail for 0 < p ≤ 1[END_REF]. Such penalties potentially have a number of desirable properties [START_REF] Wipf | A new view of automatic relevance determination[END_REF], [START_REF]Latent variable Bayesian models for promoting sparsity[END_REF]. One particularly useful non-separable penalty is given by

g α (|x|) min γ≥0 x T Γ -1 x + log |αI + ΦΓΦ T |, (15)
where α ≥ 0, Γ diag[γ], and |x|

[|x 1 |, . . . , |x m |] T .
The motivation for ( 15) is derived from a dual-space view [START_REF] Wipf | A new view of automatic relevance determination[END_REF] of sparse Bayesian learning [START_REF] Tipping | Sparse Bayesian learning and the relevance vector machine[END_REF] and automatic relevance determination [START_REF] Neal | Bayesian Learning for Neural Networks[END_REF]. The analysis in [START_REF] Wipf | A new view of automatic relevance determination[END_REF] reveals that replacing x 0 with g α (|x|) and α → 0 leaves the globally minimizing solution to (1) unchanged but drastically reduces the number of local minima (more so than any possible separable penalty function). It can be shown that g α (|x|) is a non-decreasing concave function of both |x| and x 2 [x 2 1 , . . . , x 2 m ] T [21], therefore (perhaps not surprisingly) minimization can be accomplished using either iterative reweighted 2 or 1 .

A. 2 Reweighting

There exist multiple ways to handle 2 reweighting in terms of the non-separable penalty function [START_REF] Palmer | Variational EM algorithms for non-Gaussian latent variable models[END_REF] for the purpose of solving

min x y -Φx 2 2 + λg α (|x|). (16)
Different sets of upper-bounding auxiliary functions (which are tight in different regions of x space) lead to different choices for W (k) with different properties. One useful variant that reveals a close connection with Chartand and Yin's method can be derived as follows. Using standard determinant identities we get

g α (|x|) ≤ x T Γ -1 x + log |αI + ΦΓΦ T | = x T Γ -1 x + log |Γ| + log |α -1 Φ T Φ + Γ -1 | + n log α ≤ x T Γ -1 x + log |Γ| + z T γ -1 -h * (z) + n log α = n log α -h * (z) + i x 2 i + z i γ i + log γ i ( 17
)
where γ -1 [γ -1 1 , . . . , γ -1 m ] T and h * (z) denotes the concave conjugate 4 of log |α -1 Φ T Φ + Γ -1 | with respect to Γ -1 . The bound holds for all non-negative vectors z [z 1 , . . . , z m ] T . Coordinate descent over x, γ, and z (again with w (k) i = γ i ) then leads to the weight update 4 The concave conjugate is a function that arises from convex analysis and duality theory [START_REF] Boyd | Convex Optimization[END_REF]; in this instance it is computed via

h * (z) = min γ≥0 z T γ -1 -log |α -1 Φ T Φ + Γ -1 |. w (k+1) i → x (k+1) i 2 + z (k+1) i = x (k+1) i 2 + w (k) i I - (18)
w (k) i φ T i αI + ΦW (k) Φ T -1 φ i w (k)
i , which can be computed in O(n 2 m), the same expense as each solution to (3). Note that since each weight update is dependent on previous weight updates, it is implicitly dependent on previous values of x, unlike in the separable case above.

The form of ( 18) is very similar to the one used by Chartrand and Yin. Basically, if we allow for a separate i for each coefficient x i , then the update ( 6) is equivalent to the selection

(k+1) i → w (k) i I -w (k) i φ T i αI + ΦW (k) Φ T -1 φ i w (k) i . (19
) Moreover, the implicit auxiliary function from (8) being minimized by Chartrand and Yin's method has the exact same form as [START_REF] Rao | An affine scaling methodology for best basis selection[END_REF]; with the latter, coefficients that are interrelated by a non-separable penalty term are effectively decoupled when conditioned on the auxiliary variables z. And recall that one outstanding issue with Chartrand and Yin's approach is the optimal schedule for reducing (k) , which could be application dependent and potentially sensitive. So in this regard, [START_REF] Tropp | Greed is good: Algorithmic results for sparse approximation[END_REF] can be viewed as a principled way of selecting so as to avoid, where possible, convergence to local minima. In preliminary experiments, this method performs as well or better than the heuristic -selection strategy from [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] (see Section IV-A).

B. 1 Reweighting

Using similar methodology, a reweighted 1 implementation is easily derived with desirable convergence properties [START_REF] Wipf | A new view of automatic relevance determination[END_REF]. The requisite W (k+1) update is given by

w (k+1) i → ( 20
)
φ T i αI + ΦW (k) diag x (k+1) Φ T -1 φ i -1 2
for all i. This procedure is guaranteed to aid performance in the sense described by the following two results, which apply in the case where α → 0, λ → 0 (zero noise limit):

Theorem 1: When applying iterative reweighted 1 using (20), the solution sparsity satisfies x (k+1) 0 ≤ x (k) 0 .

So continued iteration can never do worse. The proof is contained in [START_REF]Iterative Reweighted 1 and 2 Methods for Finding Sparse Solutions[END_REF]. Now define spark(Φ) as the smallest number of linearly dependent columns in Φ. It follows then that 2 ≤ spark(Φ) ≤ n + 1.

Theorem 2: Assume that spark(Φ) = n + 1. For any instance where standard 1 minimization fails to find some x * drawn from support set S with cardinality |S| < (n+1) 2 , there exists a set of signals y (with non-zero measure) generated from S such that non-separable reweighted 1 , with W (k) updated using [START_REF] Wipf | A new view of automatic relevance determination[END_REF], always succeeds but standard 1 always fails.

This result is proved in [START_REF]Iterative Reweighted 1 and 2 Methods for Finding Sparse Solutions[END_REF]. Note that Theorem 2 does not in any way indicate what is the best non-separable reweighting scheme in practice (for example, in our limited experience with empirical simulations, the selection α = 0 is not necessarily always optimal). However, it does suggest that reweighting is potentially effective in a variety of situations. Before proceeding to empirical comparisons, it is worth relating Theorem 2 with results from Davies et al. ( 2008) [START_REF] Davies | Restricted isometry constants where p sparse recovery can fail for 0 < p ≤ 1[END_REF], where it is shown that for any sparsity level, there will always exist cases (albeit of measure zero) where, if standard 1 minimization fails, any admissible 1 reweighting strategy will also fail. In this context a reweighting scheme is said to be admissible if: (i) w

(1) i = 1 for all i and, (ii) there exists a w (k) min > 0 such that for all k and i, w

(k) i ≥ w (k) min and if x (k) i = 0, then w (k) i = w (k)
min . 5Interestingly, the non-separable reweighting from [START_REF] Wipf | A new view of automatic relevance determination[END_REF] does not satisfy this definition despite its effectiveness in practice (see Section IV-B below); however, in [START_REF]Iterative Reweighted 1 and 2 Methods for Finding Sparse Solutions[END_REF] we suggest slightly modified versions of admissibility that accommodate a wider class of useful algorithms. While details are deferred, more general reweighting strategies can sometimes be advantageous for avoiding local minima. Regardless, we stress the contrasting nature of Davies et al.'s result versus our Theorem 2. The former demonstrates that on a set of measure zero in x space, a large class of reweighting schemes will not improve upon basic 1 minimization, while the latter specifies that on a different set of nonzero measure on S, some non-separable reweighting will always do better.

IV. EMPIRICAL RESULTS

This section contains a few brief experiments involving the various reweighting schemes discussed herein. First we include a comparison of 2 approaches followed by an 1 example involving non-negative sparse coding.

A. Reweighted 2 Example

Monte-Carlo simulations were conducted similar to those performed in [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF], [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] allowing us to compare the separable method of Chartrand and Yin with the non-separable update (18) using α = 0. As discussed above, these two methods differ only in the effective choice of the parameter. We also include results from the related method in Daubechies et al. using p = 1, which gives us the basis pursuit (minimum 1 norm) solution, and p = 0.6 which works well in conjunction with the proscribed update based on the simulations from [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF]. Note that the optimal value of p and for sparse recovery purposes can be interdependent and [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] reports poor results with p much smaller than 0.6 when using their update.

Additionally, there is an additional parameter K associated with Daubechies et al.'s algorithm that must be set; we used the heuristic taken from the authors' Matlab code. 6 The experimental particulars are as follows: First, a random, overcomplete 50 × 250 dictionary Φ is created with iid unit Gaussian elements and 2 normalized columns. Next, sparse weight vectors x * are randomly generated with the number of nonzero entries varied to create different test conditions. Nonzero amplitudes are drawn iid from one of two experimentdependent distributions. Signals are then computed as y = Φx * . Each algorithm is presented with y and Φ and attempts to estimate x * using an initial weighting of w (1) i = 1, ∀i. In all cases, we ran 1000 independent trials and compared the number of times each algorithm failed to recover x * . Under the specified conditions for the generation of Φ and y, all other feasible solutions x almost surely have a sparsity less than x * , so our synthetically generated coefficients must be maximally sparse.

Figure 1 displays results where the nonzero elements in x * were drawn with unit magnitudes. The performance of four algorithms is shown: the three separable methods discussed above and the non-separable update given by [START_REF] Tipping | Sparse Bayesian learning and the relevance vector machine[END_REF]. For algorithms with non-convex underlying sparsity penalties, unit magnitude coefficients can be much more troublesome than other distributions because local minima may become more pronounced or numerous [START_REF]Latent variable Bayesian models for promoting sparsity[END_REF]. In contrast, the performance will be independent of the nonzero coefficient magnitudes when minimizing the 1 norm (i.e., the p = 1 case) [START_REF] Malioutov | Optimal sparse representations in general overcomplete bases[END_REF], so we expect this situation to be most advantageous to the 1 norm solution relative to the others. Nevertheless, from the figure we observe that the non-separable reweighting still performs best; out of the remaining separable examples, the p = 1 case is only slightly superior. sep, p = 1.0, ε update from [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] sep, p = 0.6, ε update from [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] sep, p = 0.0, ε update from [START_REF] Chartrand | Iteratively reweighted algorithms for compressive sensing[END_REF] non-sep placements x * 0 p(success) http://www.ricam.oeaw.ac.at/people/page/fornasier/menu3.html performance of the p = 1 separable algorithm is unchanged as expected; however, the others all improve significantly, especially the non-separable update and Chartrand and Yin's method. Note that we have also included a second nonseparable variant labeled 'non-sep+' in which we added an additional decaying regularization term to [START_REF] Tipping | Sparse Bayesian learning and the relevance vector machine[END_REF]. Although we adopted a simple heuristic for this task (like Chartrand and Yin's method), based on results in the figure, this demonstrates that better performance is definitely possible and that [START_REF] Tipping | Sparse Bayesian learning and the relevance vector machine[END_REF] is by no means optimal. Of course presumably all of these methods could be improved through additional modifications and tuning (e.g., a simple hybrid scheme is suggested in [START_REF] Daubechies | Iteratively re-weighted least squares minimization for sparse recovery[END_REF] that involves reducing p after a 'burn-in' period that improves recovery probabilities marginally); however, we save thorough evaluation of such extensions to future exploration.

B. Non-Negative Sparse Coding Example via Reweighted 1 Minimization

As an example of non-separable 1 reweighting, we performed a simple experimental test similar to the previous section. Each trial consisted of generating a 50×100 dictionary Φ with iid Gaussian entries and a sparse vector x * with 30 nonzero, non-negative coefficients. A signal is computed using y = Φx * as above. We then attempted to recover x * by applying non-separable 1 reweighting to y and Φ, with a non-negativity constraint applied to (4) at each iteration and using α = 1. This selection was found to work somewhat better than α = 0 (as was used for reweighted 2 ), although we have not fully explored what the optimal value might be. Since we are working with a noise-free signal, we also assume λ → 0 and so the requisite coefficient update becomes

x (k+1) → arg min x i x i w (k) i , s.t. y = Φx, x i ≥ 0, ∀i, (21)
which can be solved using a straightforward linear program. Assuming W (1) = I, then the first iteration amounts to the non-negative minimum 1 solution. Results from 1000 random trials are displayed in Figure 3, where standard non-negative 1 succeeds less than 40% of the time; however, with only four reweighted iterations using [START_REF] Wipf | A new view of automatic relevance determination[END_REF], success improved to almost 90%. This demonstrates both the efficacy of reweighting and the ability to handle constraints on x.

V. DISCUSSION

In this paper we have briefly explored various iterative reweighting schemes for solving sparse linear inverse problems, elaborating on a distinction between separable and nonseparable weighting functions. Although a large number of separable algorithms have been proposed in the literature, the non-separable case is relatively uncommon and, on the surface, may appear much more difficult to work with. However, iterative reweighted 1 and 2 approaches provide a convenient means of decoupling coefficients via auxiliary variables leading to efficient updates that can potentially be related to existing separable schemes. In general, a variety of different algorithms are possible by forming different upper-bounding auxiliary functions. While the non-separable algorithms we have discussed show considerable promise, we envision that superior strategies and interesting extensions are very possible.

One direction of future research is the application and analysis of various reweighting schemes to the simultaneous sparse approximation problem, which is a special case of covariance component estimation [START_REF] Wipf | A new view of automatic relevance determination[END_REF]. In this scenario we are presented with multiple signals y 1 , y 2 , . . . that we assume were produced by coefficient vectors x * 1 , x * 2 , . . . characterized by the same sparsity profile or support. All of the algorithms discussed herein can naturally be expanded to this domain by applying an 2 norm penalty to the aligned elements of each coefficient vector. With reweighted 2 , this transition is very straightforward and easy to implement. In contrast, reweighted

Fig. 1 .

 1 Fig. 1.Iterative reweighted 2 example using unit magnitude nonzero coefficients. Probability of success recovering sparse coefficients for different sparsity values, i.e., x * 0 .

Figure 2

 2 Figure 2 reproduces the same experiment with nonzero elements in x * now drawn from a unit Gaussian distribution. The

6

 6

Fig. 2 .

 2 Fig. 2. Iterative reweighted 2 example using Gaussian distributed nonzero coefficients. Probability of success recovering sparse coefficients for different sparsity values, i.e., x * 0 .

Fig. 3 .

 3 Fig.3. Non-negative sparse coding example. Probability of success recovering sparse, non-negative coefficients as the number of reweighted 1 iterations is increased.

For notational convenience, our definition of the weights is the reciprocal of the weights used in several other papers.

Square-concavity implies that g(|xi |) = f (x 2 i ), where f (•) is concave.

Note that the convergence analysis we discuss above applies for any sequence of (k) → 0 and can be extended to other values of p ∈ [0, 1).

Note that we have modified this definition slightly to account for the fact that we define our weights as the reciprocal of those used in[START_REF] Davies | Restricted isometry constants where p sparse recovery can fail for 0 < p ≤ 1[END_REF].

requires the solution of a second-order-cone program at each iteration. Preliminary results indicate that non-separable methods can significantly widen their performance advantage over their separable counterparts in this domain.

ACKNOWLEDGMENT

This research was supported by NIH grants R01DC04855 and R01DC006435. Also, thanks to the reviewers for suggesting reference [6] and other useful comments.


Example: A woman is interacting with a robot, which has to turn its head towards her for natural social interactions.

Biological constraints in neural field models of sensor fusion

Objectives

• Improve the way social robots interact with people, starting with the way they perceive their environment • Particular focus on multimodal merging + role of active perception • Sensor fusion performed very efficiently in human brains ⇒ inspiration from psychology and neuroscience (e.g. the ventriloquist effect, where one modality takes over another for determining the perceived location of a sensory cue) ⇒ Create a computational model that accounts for human "biases" (such as the ventriloquist effect) and, in the longer term, includes active perception in order to support the development of more natural interactions (e.g. with a human environment) • Part of the AMPLIFIER project ⇒ applications to social robotics + validation by psychophysical experiments

The AMPLIFIER project "Active Multisensory Perception and LearnIng For InteractivE Robots" An interdisciplinary project with three main components:

• Gathering psychophysical data on sensor fusion, and in particular the role of active perception (e.g. eye movements) • Building biologically-inspired computational models of multimodal merging, in adequation with the new data • Using this model to enhance robot perception and improve their social interactions More information: https://projet.liris.cnrs.fr/amplifie/wiki/

Hypotheses

Model inspired from the superior colliculus (SC):

• Subcortical region involved in both multimodal merging and saccade generation • Receiving visual, auditory, and even somatosensory inputs • Aligned receptive fields: visual, auditory and somatosensory signals at a same location activate the same region of the SC Reproducing the topology of the SC with a logpolar transformation:

         x = B x log ( √ ρ 2 + 2Aρ cos ϕ + A 2 A ) y = B y arctan ( ρ sin ϕ ρ cos ϕ + A )
Since the retina has a denser distribution of sensors at its center, visual cues will activate more SC neurons when they are close to the fovea than at the periphery.

[3]

Model

Based on dynamic neural fields [START_REF] Amari | Dynamics of pattern formation in lateral-inhibition type neural fields[END_REF]:

τ ∂U (x, t) ∂t = -U (x, t) + I(x, t) + ∫ SC W (∥x -x ′ ∥) f (U (x ′ , t)) dx ′ + h W (∆x) = A + exp ( - ∆x 2 σ 2 + ) -A -exp ( - ∆x 2 σ 2 - ) • Mesoscopic

  modeling of the SC • Able to merge conflicting signals and/or select one of them • Succeeds in qualitatively reproducing psychophysical experiments on the ventriloquist effect 1. The model receives inputs from the camera and microphones and merges it. 2. The perceived location of the signal can be used to finetune the head-related transfer function (HRTF), specific to each subject. 3. The model can generate saccades (or head movements) autonomously [

  Simon Forest, Mathieu Lefort, and Jean-Charles Quinton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . simon.forest@liris.cnrs.fr


Final version online at this address: http://www.water-alternatives.org/index.php/boh/item/244-turkey __________________________________________________________________________________ Review of "Turkeys water diplomacy: Analysis of its foundations, challenges and prospects". Kibaroglu, A. 2021. Turkeys water diplomacy: Analysis of its foundations, challenges and prospects. Anthem Press. ISBN:9781783088133, 184 p., $30.36. URL: https://anthempress.com/turkey-s-water-diplomacy-epub Selin Le Visage Université de Pau et des Pays de l'Adour, E2S UPPA, CNRS, TREE, Pau, France ; s.levisage@gmail.com To cite this review: Le Visage, S. 2020. Review of " Turkeys water diplomacy: Analysis of its foundations, challenges and prospects", Anthem Press, 2021, by Aysegül Kibaroglu, Water Alternatives, http://www.wateralternatives.org/index.php/boh/item/244-turkey In the current tense political context of north-east Syria, Kurdish authorities regularly accuse Turkey of withholding water from the Euphrates. Recently, a coordination of NGOs in the region expressed concern about the low flow of the river since the end of January 2021, and when the UN Under-Secretary-General for Humanitarian Affairs highlighted the problematic situation last May, the Turkish Ministry of Foreign Affairs sent a statement to the UN, saying that Turkey was fulfilling its commitments1 . This recent example is a further reminder of Turkey's poor reputation on the international stage regarding transboundary waters. Ayşegül Kibaroğlu's new book focuses on the evolution of Turkey's foreign policy and water diplomacy, in a very synthetic format (171 pages, bibliography and index included). It offers an explanation of Turkey's official position towards transboundary water management and international law. The research approach claims to be "qualitative and normative" and is based on an analysis of legal documents, memoranda of understanding, official reports, etc.

The author is specialised in water policy and international relations and it is clear that her work has benefited from a rich dialogue over time with actors of Turkish diplomacy, water bureaucracy and thinktanks such as the Hydropolitical Academy. On the other hand, and given the author's rich experience with the Euphrates-Tigris basin (as an advisor at the Regional Development Administration of the GAP2 project and as a co-founder of a Track II initiative3 ), I regretted that the analysis did not provide more details regarding the negotiation processes themselves or the dynamics at work alongside the official reports, or beyond the official discourse of Turkey with regard to international law.

The first three chapters detail the institutional setting and the guiding principles of Turkey's water diplomacy. Chapter 1 presents the evolving role of the different state actors involved in transboundary water policy-making (Ministry of Foreign Affairs, water administrations, etc.). Chapter 2 presents the main principles adopted by Turkish water diplomacy circles (preference for technical collaborations and joint development projects to favour benefit-sharing rather than water flow sharing, reluctance to third party involvement for the mediation of transboundary water disputes, etc.). Chapter 3 traces the evolution of Turkey's position vis-à-vis international water law, including the reasons for its rejection of the UNWC convention (as a reminder, only Turkey, China and Burundi voted against it in 1997). There are many repetitions (sometimes almost word for word) throughout the introduction and these first three chapters, despite the short format of the book. This first part of the book will certainly be of great benefit to students interested in diplomacy and international water law and, more generally, it offers a clear reading of the legal foundations mobilised by Turkey to justify its official position on transboundary water management. While the introduction briefly mentions the importance of Turkey's developmentalist perspectives at the national level (especially with regard to energy and irrigation) in shaping its water diplomacy, the role of the political and economic factors remains little explored in these three chapters4 .

The value of chapter 4 is to expose the bilateral relations of Turkey with other states in different transboundary basins (we can note the emphasis, in the titled of the chapter, placed on the 'role of history and [physical] geography', rather than on politics or economics). Evolution of international relations is described in each of the five cases studied, where the object of the disputes is either the guaranteed river flow (Euphrates-Tigris, Aras, Orontes), the sediment flow (Çoruh) or flood protection (Meriç). Following these successive rich descriptions, a synthetic cross-reading on Turkey's foreign policy would have been very welcome. Finally, the fifth and last chapter offers an interesting perspective to decentring the reading by highlighting the role of non-state actors in Turkey's water diplomacy. The example of the Euphrates-Tigris Initiative for Cooperation (ETIC; a group of scholars and professionals from Turkey, Syria and Iraq that the author co-founded, and which organises training and research projects in the three countries) stresses the role of epistemic communities in water diplomacy and international relations. The book also mentions the role of some large NGOs and engineering associations in the production of knowledge on transboundary water management, but the discourse of critical voices remains little developed as such.

The book deals mainly with transboundary surface waters, but, after reading it, one would like to know more about the issue of transboundary aquifers too. Moreover, water diplomacy is not limited to the issue of transboundary waters, as shown by the examples given by A. Kibaroğlu on humanitarian aid that Turkey is trying to develop through water projects. As a result, I was surprised that the book did not address the case of the mega-infrastructure of the Turkey-Northern Cyprus water pipeline, which was recently analyzed in terms of 'hydraulic patronage' defined as the "systemic provision of water resources by a patron state to a client territory" [START_REF] Mason | Hydraulic patronage: A political ecology of the Turkey-Northern Cyprus water pipeline[END_REF].

Readers of Water Alternatives will not find in this book an engaged discussion of recent literature on the subject in political ecology or critical hydropolitics for example, or of currently debated analytical frameworks such as the framework of hydro-hegemony (FHH) [START_REF] Menga | Reconceptualizing hegemony: The circle of hydro-hegemony[END_REF][START_REF] Conker | Hydropolitics and issue-linkage along the Orontes River Basin: An analysis of the Lebanon - Syria and Syria - Turkey hydropolitical relations[END_REF] - the word 'hegemon' appears once and the way in which some states benefit more than others from perpetuating a status quo is not explicitly addressed. As another example, the focus on diplomacy certainly makes sense when seeking a shift from conflict to cooperation potential, but the conflictcooperation nexus (TWINS, [START_REF] Mirumachi | Transboundary water politics in the developing world[END_REF] is not addressed at all, not even mentioned.

Engaging with these debates was probably not the aim of this book. Rather, the book added value is in tracing, in detail, the evolution of Turkey's official position and the various arguments it uses to justify it, and this will certainly be useful to a wide audience interested in geopolitics or international relations in the Middle East.

Turkey has been committed to delivering annually an average flow of 500 m3/s since the signing of a bilateral agreement with Syria in 1987.

Güneydoğu Anadolu Projesi, or Southeastern Anatolia Project. This project targeted the construction of 22 dams and 19 power plants in the basins of the Euphrates and the Tigris.

i.e. unofficial diplomacy, led by non-state agents (such as NGOs or universities) willing to avoid conflicts by improving the understanding of various points of view and thus communication between states.

For instance, the Kurdish issue is quickly brought up to explain which security negotiations with Syria were key to the bilateral agreements signed by then Prime Minister Turgut Özal in 1987, but not to explain the very necessity of the GAP for the Turkish state as a means of internal territorial control[START_REF] Akıncı | Development through design: Knowledge, power, and absences in the making of southeastern Turkey[END_REF].

Additional Info

Authors: Aysegül Kibaroglu Year of publication: 2021 Publisher: Cambridge University Press Reviewer: Selin Le Visage Subject: Water policy, Water governance, Water politics, Irrigation, Hydrocracies, Dams Type : Introduction Language: English