Sami Lazreg

Maxime Cordy

Philippe Collet

Patrick Heymans

Sébastien Mosser

Sébastien

Multifaceted Automated Analyses for Variability-Intensive Embedded Systems

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

In many embedded systems, requirements engineering and design activities are tightly intertwined and involve complex multi-criteria decision-making over various concerns. As an example, let us consider an infotainment feature in an automotive system. Specifying such a feature typically entails defining a set of functional and non-functional (aka. quality) requirements. Functional requirements define, for example, not only what content should be displayed through the Human Machine Interface (HMI), but also constraints imposed by the hardware , like not exceeding the available memory. Typical examples of non-functional requirements constrain manufacturing costs or execution time. A notoriously difficult problem is to establish whether such a set of requirements is feasible and what is the best design to implement it.

Design options are not only constrained by the requirements but also by the existing software and hardware architectures. In our case, an HMI-rendering automotive system consists of (1) a data processing application (i.e., data-flow oriented embedded software) and (2) a resource-constrained hardware platform (i.e., heterogeneous hardware components like nonprogrammable processors and data storage units). The application and the platform are, however, not completely fixed as they have variation points. There are three main sources of extensive variability. First, at the application level, multiple data-flow variants can achieve the functional requirements, differing in, e.g., the size of the flowing data chunks, the ordering of the operation tasks, or the choice between alternative, functionally-equivalent tasks. Second, there exists a diversity of configurable hardware platforms which can differ, e.g., in memory capacities and processing pipelines. Third, there are various ways of mapping and deploying a given application on a specific platform, e.g., choose a processor to perform a given task or select a memory unit to store a given data.

This threefold variability is typical in automotive and many other kinds of embedded systems [START_REF] Pretschner | Software engineering for automotive systems: A roadmap[END_REF]. Unfortunately, it leads to a high number of variants [START_REF] Pretschner | Software engineering for automotive systems: A roadmap[END_REF]548,288 in this particular case), each of which represents a specific system design alternative (or design for short), that is, a specific mapping of a specific application variant to a specific platform variant. Among these design alternatives, not all are able to realize the functional requirements to the same extent, and the same holds for the non-functional requirements. Given the sheer number of variants, a systematic consideration of all design alternatives is unfeasible for the software and system engineers whereas the high level of competition in industry puts a high pressure on them to deliver optimal solutions and do so timely [START_REF] Broy | Cross-layer analysis, testing and verification of automotive control software[END_REF]. Efficient automations therefore appear as a necessity.

Examples of questions the engineers need to quickly answer are: Can the specified HMI be properly rendered on platform X? Which feasible designs can be built with a budget of Y? Which feasible designs can execute in less than Z time? Which feasible designs, with a rendering quality higher than P and a manufacturing cost lower than Q, exhibit the fastest execution time? Which feasible designs reach the best tradeoff between rendering quality, manufacturing cost and execution time? Answering those questions not only requires a way to deal with the variability-induced combinatorial explosion (see previous paragraph), but also a way to reason simultaneously about different types of concerns: feasibility/satisfiability and optimality; functional and non-functional requirements; the structure and the behaviour of the system. Although significant progress was made in the recent years to automate reasoning on variability-intensive systems, existing solutions only address specific facets of the problem in isolation. As revealed by our experiments, partial solutions give suboptimal designs, while complete but non-variability-aware solutions do not scale. Hence the need for multifaceted, variability-aware analyses capable of answering all the above questions.

Without such solutions, engineers mostly resort to intuition and experience. Theoretical analyses can be made but are timeconsuming and often turn out largely suboptimal, if not completely wrong. Simulators are sometimes provided by platform suppliers but analyzing all system variants requires simulations for all of them, which is unrealistic. Quick prototyping may occur when the platform is finally supplied but it is then too late to backtrack if the wrong platform was picked. In the end, current practices are deemed very unsatisfactory.

These observations were made by our partner Visteon Electronics, an international leader in automotive systems, and are corroborated by surveys such as [START_REF] Broy | Challenges in automotive software engineering[END_REF]. They formed the motivation for the industry-academia partnership which led to this research effort. In this paper, we propose an approach that combines and extends existing research results in order to provide the first tooled framework able to solve the multifaceted problem described above. Our contributions are:

1) modelling languages based on Y-chart [START_REF] Balarin | Hardware-software co-design of embedded systems: the POLIS approach[END_REF], [START_REF] Kienhuis | An approach for quantitative analysis of application-specific dataflow architectures[END_REF] to capture functional and non-functional specifications of variability-intensive embedded systems that can vary at both the application and platform levels; 2) mapping algorithms to derive, from the application and platform models, the resulting design space (i.e. all design alternatives) while capturing all the structural, behavioural, functional and non-functional variations; 3) the first variability-aware model-checking algorithm to optimize multiple behaviour-dependent quality attributes across all variants; 4) an integrated tool chain to evaluate the functional feasibility and the non-functional satisfiability and optimality of the whole design space at once; 5) qualitative and quantitative evaluations of the approach based on a real system developed by Visteon. The qualitative evaluation shows that functional and non-functional requirements were properly captured by our framework, and optimal system designs were correctly identified. The quantitative evaluations assess the scalability of our approach and give us confidence that our framework is applicable to the majority of Visteon's systems and similar systems developed elsewhere in industry. Although its motivation originates from an industrial partnership, our contribution is not domain specific. Our modelling method covers a large class of variability-intensive data-floworiented systems with quality attributes. Our model-checking algorithm is language-independent and can be applied to a broader range of variability-intensive systems.

II. INDUSTRIAL CASE STUDY

This research originates from a collaboration with Visteon Electronics, a leading company developing solutions for the automotive industry such as instrument clusters, infotainment and connected vehicles. In this section, we introduce a simplified exerpt of the system we use in our evaluations (see Sec. VIII) to further illustrate and justify our approach.

An instrument cluster generally consists of a speedometer and other instruments which, unlike traditional analog gauges, appear on an electronic visual display (see Fig. 1). By applying various data-flow image processing effects (e.g., 3D gauges, 3D view of the car), it improves the driving experience.

To achieve economies of scale, such systems are often built and sold to car manufacturers as product lines, which have to meet and optimize the manufacturers' variable requirements for an entire range of cars. To be competitive, they are highly constrained on quality and cost. As such, one must know as early as possible in the development whether the expected HMI can be rendered properly on a candidate platform.

At industrial scale, the threefold variability introduced in Sec.I (i.e. from application, platform and mapping) prevents any product-based exhaustive feasibility checking, let alone exhaustive reasoning/optimization on quality attributes (e.g. cost, rendering quality, runtime). Yet, some separation of concerns is intrinsically possible as data-flows can be abstracted from the implementation by domain experts (i.e. rendering engineers). Platforms are already specified by hardware experts to organize competitive tendering on hardware providers. Fig. 2 shows an example of data-flow specification with quality attributes. The different processing flows that meet the HMI functional requirements are captured by a variable dataflow. Images are processed by graphical tasks. Image D1 can be processed by tasks A or B. D2 has three different possible resolutions and is processed by task D. The images produced by A (or B) and D are then processed by task C, which delivers the final result. Task and image resolution impacts the HMI rendering quality. In our case, performing B instead of A significantly improves the rendering quality. Also, as the resolution of D2 is increased, the overall quality raises as well.

At the platform level (Fig. 3), image processing functions A,B,C,D are provided by a non-programmable Graphical Processing Unit (GPU) and an advanced Display Controller Unit (DCU). Within DCU, there are three functions (A, C and D)

Legend

Processor Fig. 3: Platform Specification Input Model and two buffers (R0 and R1). Directed edges denote the flows followed by data that transit through the processing pipeline of processors, while functions may be applied or not. The platform also includes data storage on RAM and ROM. GPU and RAM are optional as everything can be stored in ROM and then rendered directly to the screen by DCU. Yet, they improve the runtime efficiency for a higher manufacturing cost. There is a presence condition between RAM and GPU as RAM acts as a dedicated cache memory for GPU, while RAM can be used without GPU, e.g., to store more data or larger images. RAM comes in three alternative capacities (at different costs). Similarly, RAM, GPU and ROM have two possible frequencies.

Frequency acts as a scale factor for data processing/transfer bandwidth for processors and memories. Our overall goal is to assist engineers in determining which variants (i.e. alternative designs consisting of a data-flow variant deployed on a platform configuration) of the instrument cluster can satisfy the imposed functional (FC) and nonfunctional (NF) requirements.

To ensure the executabilty of the application on the platform, a first FC requirement states: "Any data required by a task must be stored in a memory storage accessible to the processor that processes the task". Its satisfaction depends only on the structure of the design, e.g. which tasks must be processed, which tasks exchange data with each other, which memory storage is accessible by the processors, and how tasks (resp. data) are mapped onto processors (resp. memory storage). Another FC requirement states that the execution of the application on the platform must eventually terminate. This not only depends on the structure of the design but also on its runtime behaviour, as bad scheduling of tasks and data transfers may cause deadlocks. Checking the satisfaction of this requirement by a given design is more complicated, as it requires analysing many (if not all) its executions.

In addition to FC requirements, the design must also meet NF requirements. These commonly include a maximal manufacturing cost, a minimal rendering quality, and a maximal execution time (i.e. time to render graphics on the visual display).

Manufacturing cost and rendering quality are quality attributes which depend only on the structure of the design (e.g. size of input data, choice between alternative tasks, components of the platform). Execution time, however, depends on both structure (e.g. processor frequency) and behaviour (e.g. scheduling of tasks and memory access operations).

Those requirements are not enough, though, as market competition forces engineers to deliver the best system to each specific customer. Among the variants, they must thus find those offering the best trade-off between the quality attributes.

Achieving our goal thus requires solving the problem of efficiently identifying the variants that:

1) Satisfy the FC requirements. We further decompose this sub-problem in two challenges: (a) checking the FC requirements that depend only on the structure of the design (challenge FCS) and (b) checking FC requirements that depend also on its behaviour (FCB). 2) Satisfy the NF requirements, that is, checking: (a) those that depend only on the structure (NFS) and (b) those that also depend on the behaviour (NFB). 3) Optimize the trade-off between the quality attributes (NFOB). This challenge requires considering all quality attributes. Optimizing only those that depend on the structure (NFOS) is easier, but leads to suboptimal solutions (as revealed by our evaluations). We must solve all those challenges to give engineers the means of making appropriate design decisions at an early stage.

III. STATE OF THE ART AND RELATED WORK

Many approaches were proposed to tackle parts of the above challenges. First, research in variability modeling is black-box oriented and focused on structural aspects. It attempts to assess [START_REF] Khalilov | Modeling and optimizing automotive electric/electronic (e/e) architectures: Towards making clafer accessible to practitioners[END_REF], [START_REF] Ross | Synthesis and exploration of multi-level, multi-perspective architectures of automotive embedded systems[END_REF] or efficiently predict [START_REF] Guo | Data-efficient performance learning for configurable systems[END_REF]- [START_REF] Valov | Transferring performance prediction models across different hardware platforms[END_REF] non-functional properties of the whole product line, thus tackling both FCS and NFS. Extensions of these methods with multi-objective optimization [START_REF] Olaechea | Modelling and multi-objective optimization of quality attributes in variability-rich software[END_REF]- [START_REF] Olaechea | Long-term average cost in featured transition systems[END_REF] allow to find optimal variants wrt. structural quality attributes, thereby solving NFOS. However, those approaches lack reasoning support on the system behaviour and are thus unable to, e.g., search for optimal schedulings.

Behavioural analyses of variable systems were addressed by variability-aware model checking against functional requirements (challenge FCB) [START_REF] Asirelli | Formal description of variability in product families[END_REF]- [START_REF] Lazreg | Assessing the functional feasibility of variability-intensive data flow-oriented systems[END_REF] or one particular nonfunctional aspect (e.g. real time [START_REF] Cordy | Behavioural modelling and verification of real-time software product lines[END_REF]- [START_REF] Luthmann | Modeling and testing product lines with unbounded parametric real-time constraints[END_REF], reliability [START_REF] Nunes | Variability management of reliability models in software product lines: An expressiveness and scalability analysis[END_REF], [START_REF] Rodrigues | Modeling and verification for probabilistic properties in software product lines[END_REF], income [START_REF] Olaechea | Long-term average cost in featured transition systems[END_REF], quality of service [START_REF] Olaechea | Trace checking for dynamic software product lines[END_REF]). Resource-optimal execution [START_REF] Behrmann | Priced timed automata: Algorithms and applications[END_REF]- [START_REF] Bertrand | Refinement and consistency of timed modal specifications[END_REF] and worst-case execution time [START_REF] Cassez | Wuppaal: Computation of worst-case execution-time for binary programs with uppaal[END_REF] are still determined product by product. Also, contrary to our framework, these approaches are unable to automatically map variable workflow specifications on configurable platform descriptions in order to infer a system design space. Therefore, applying them obliges to manually model and assess all possible systems designs. They thus inefficiently tackle NFOB. Even when both levels are captured in software/hardware product lines with dependencies and constraints [START_REF] Liebig | Robbydbms: a case study on hardware/software product line engineering[END_REF]- [START_REF] Adler | Componentbased modeling and verification of dynamic adaptation in safety-critical embedded systems[END_REF], the expressiveness is also insufficient, because either behaviour is not considered or only functional requirements are checked. Some system design frameworks [START_REF] Balarin | Hardware-software co-design of embedded systems: the POLIS approach[END_REF], [START_REF] Marwedel | Embedded system design: Embedded systems foundations of cyber-physical systems[END_REF]- [START_REF] Chadli | High-level frameworks for the specification and verification of scheduling problems[END_REF], model, assess and optimize quality attributes (NFB and NFOB), but do not capture nor manage all variability dimensions. Specific techniques attempt to efficiently handle either platform variability [START_REF] Sima | Runtime decision of hardware or software execution on a heterogeneous reconfigurable platform[END_REF]- [START_REF] Palermo | Variability-aware robust design space exploration of chip multiprocessor architectures[END_REF], application variability [START_REF] Schor | Scenario-based design flow for mapping streaming applications onto on-chip many-core systems[END_REF]- [START_REF] Palermo | Robust optimization of soc architectures: A multi-scenario approach[END_REF] or deployment variability [START_REF] Noir | A decision-making process for exploring architectural variants in systems engineering[END_REF], but they are limited to one dimension at a time and cannot reason on the whole problem.

Other approaches [START_REF] Graf | Ivam: Implicit variant modeling and management for automotive embedded systems[END_REF]- [START_REF] Lukasiewycz | Efficient design space exploration of embedded platforms[END_REF] tackle both functional and platform variabilities by focusing on an optimal platform configuration for a multi-variant application. Contrarily to our solution, they do not find a design (i.e., a mapping of a functional variant onto a platform configuration) that ensures an optimal execution. Our recent work [START_REF] Lazreg | Assessing the functional feasibility of variability-intensive data flow-oriented systems[END_REF] can capture and reason on variability at all three levels. It is, however, limited to functional requirements (challenges FCS and FCB).

IV. OVERVIEW OF THE FRAMEWORK

Our approach follows the model-driven Y-Chart process [START_REF] Balarin | Hardware-software co-design of embedded systems: the POLIS approach[END_REF], [START_REF] Kienhuis | An approach for quantitative analysis of application-specific dataflow architectures[END_REF] which explicitly separates application and platform. This allows for the modular specification of, and the reasoning on, the different parts of the system. As shown in Fig. 4, our framework involves several models and processes. On the left, the inputs are application and platform models such as those of Fig. 2 and Fig. 3. Domain experts are expected to model the application as an extended concurrent data-flow model with quality attributes. The model contains the classic structure and behaviour of the data-flow (data, task, edge) and its variability. Additionally, platform experts provide the platform specification as a templated concurrent componentbased system, which also captures platform variability.

First process (detailed in Sec. V): from the input models the framework generates a variability-intensive design space that captures all valid deployment mappings of the variable application onto the configurable platform. A mapping basically allocates tasks to processors and data to memory components.

Second process (detailed in Sec. VI): from the design space, we generate representations that allow for reasoning on the structure and the behaviour of all designs. In addition to the input models, experts define the NF requirements as constraints and a cost function representing trade-offs between quality attributes. To relate NF requirements with the design space, we rely on feature models with quality attributes [START_REF] Siegmund | Spl conqueror: Toward optimization of non-functional properties in software product lines[END_REF], [START_REF] Olaechea | Modelling and multi-objective optimization of quality attributes in variability-rich software[END_REF] for the structural part, and on featured transition systems [START_REF] Classen | Featured transition systems: Foundations for verifying variability-intensive systems and their application to ltl model checking[END_REF] with added weights [START_REF] Fahrenberg | Featured weighted automata[END_REF] for the behavioural part.

Third process (detailed in Sec. VII): we reuse featuremodel reasoning and apply our new model-checking algorithms to identify the designs that meet the requirements (FCS, FCB, NFS and NFB) and are optimal (NFOB). Additionally, we can provide the execution traces that optimize the quality attributes while satisfying the requirements. Such a trace shows not only the designs able to execute it but also the behaviour it exhibits (i.e., how the application tasks are executed and scheduled onto the platform), thereby helping the upcoming engineering of the designs.

V. APPLICATIONS, PLATFORMS AND MAPPINGS

To model the application, the platform and their quality attributes, we extend our former modelling framework [START_REF] Lazreg | Assessing the functional feasibility of variability-intensive data flow-oriented systems[END_REF] to support NF requirements, as it is limited to checking designs that satisfy the FC requirements. Thus, we define formal models for variable dataflows and configurable platforms.

Definition 1: A variable data-flow graph is a tuple V DG = (N, P, E, Ψ, χ d ) where N = T ∪ D is a set of nodes (T are tasks and D are data); P is a set of communication paths by which data flows between producers (tasks and data) and consumers (tasks); E ⊆ N ×P ×T is the set of flow processing between producers and consumers via available paths; Ψ is a set of attributes; χ d : N → (Ψ → ψ∈Ψ ν(ψ)) → {true, f alse} is a function that associates a node n to the set of values that (all or a subset of) the attributes in Ψ can take, where ν(ψ) is the finite set of values that ψ can take. Intuitively, these graphs encode two forms of variability. The first consists of variations in the data flow, as we allow data paths to have multiple connected producers and consumers; this follows the same approach as in variable workflows [START_REF] Graf | Ivam: Implicit variant modeling and management for automotive embedded systems[END_REF]. The second lies in the alternative attribute values that a node can take. For example, consider again Fig. 2. We see that datum D2 can have three size values. This corresponds to a design variation of the application (i.e. the size of the processed data). On the contrary, the quality of D2 represents the impact of data size on the overall quality of the system, which is also determined by the quality value of B. Thus, the overall quality depends on (i) the size of D2 and (ii) whether A or B consumes D1. In our case study, the property value of the system is obtained by summing the property values of its constituents. We make this assumption in the rest of the paper, without loss of generality: one can use instead other aggregation functions (e.g. average, maximum).

Our definition of χ d allows one to define cross-cutting constraints over the attribute values of a given node n. For instance, the quality value of D2 is directly linked to its size property: a size of 256 leads to a quality of 0, 512 to 1, and 1024 to 3. We see that χ d (n) defines which valuations of the attributes are valid altogether. This flexible definition, akin to the notion of configuration of non-boolean parameters [START_REF] Fleischanderl | Configuring large systems using generative constraint satisfaction[END_REF]- [START_REF] Felfernig | Knowledge-based Configuration: From Research to Business Cases[END_REF], can express that some attribute values are forbidden in n, and that the value of given attributes in n restricts the values of the others.

Definition 2: A variable resource graph is a tuple V RG = (R, C, Θ, Ψ, χ r ) where R = P ∪S is a set of resources (P are processors and S are memory storage); C ⊆ (S ×P )∪(P ×S) is a set of connections between processors and storage, where (p, s) ∈ C (resp. s, p ∈ C) means that processor p writes from (resp. reads to) storage s; Θ : 2 R → {true, f alse} encodes which subsets of resources constitute a valid platform configuration; Ψ is a set of attributes; χ r : R → (Ψ → ψ∈Ψ ν(ψ)) → {true, f alse} associates a resource r to the set of values that the attributes in Ψ can take.

The function χ r is defined similarly to its counterpart in variable data-flow graphs and offers the same benefits. Another source of variability encoded by this model comes from the optional nature of resources, that is, two variants of the platform may differ by their constituent resources. Θ symbolically encodes which subsets of resources constitute a valid platform in the form of Boolean constraints.

The third and last part of our formal model is the mapping rules that must be satisfied to deploy any given application variant on any given platform variant. These rules are automatically generated from the variable data-flow graph and the variable resource graph. A mapping allocates each task to at least one processor function, each datum to at least one memory storage, and each path to at least one buffer or memory storage. A valid mapping must ensure that the required data can be read and written by the hardware functions using them. For each path p, producer node i and consumer task o of p, there must exist a buffer or storage b associated to p, a function f i associated to i, and a function f o associated to o, such that f i can write to b and f o can read from b.

Altogether, the two graphs and their mapping rules constitute the variability-intensive design space, as they define the set of the design alternatives that can result from a valid deployment of a variant of the application onto a configuration of the platform.

VI. ENABLING REASONING ON THE DESIGN SPACE

From the variability-intensive design space, we generate intermediate representations to reason on the structure and the behaviour of all variants and on their quality attributes.

In product-line engineering [START_REF] Clements | Software Product Lines: Practices and Patterns, ser[END_REF], structural variability is commonly addressed by modelling features and their interdependencies as a feature model (FM) [START_REF] Kang | Featureoriented domain analysis (FODA) feasibility study[END_REF]. Since we consider NF requirements, we use an extension of FMs where features have quality attributes [START_REF] Siegmund | Spl conqueror: Toward optimization of non-functional properties in software product lines[END_REF], [START_REF] Olaechea | Modelling and multi-objective optimization of quality attributes in variability-rich software[END_REF], [START_REF] Benavides | Automated reasoning on feature models[END_REF], which we name Priced Feature Model (PFM). Reasoning on the PFM allows for determining which design variants satisfy the requirements that depend on the structure of the design (FCS and NFS).

Definition 3: A PFM is a tuple pf m = (F, Q, Ψ ρ , η, Ψ τ ) where F is a set of Boolean features; Q is a set of positive real-valued quality attributes; Ψ ρ is a set of cross-cutting constraints over F defining which subsets of features form a valid variant; η : F × Q → R + 0 is a function defining how each f ∈ F changes the value of each q ∈ Q; Ψ τ is a set of constraints over Q defining what are the valid aggregated values for a given attribute q. The semantics of a PFM is a partial function pf m : 2 F → Q → R + 0 such that (i) pf m is defined only for the valid variants: F ∈ dom( pf m ) ⇔ F |= Ψ ρ ; (ii) the aggregated value of each attribute q satisfies the constraints: ∀q ∈ Q : η(F , q) |= Ψ τ ; (iii) each attribute is associated with its aggregated value: pf m (F , q) = η(F , q) where η(F , q) is the aggregated value of q in the variant represented by F ⊆ F .

An excerpt of PFM is shown in Fig. 5. Each variation point that may occur in the application (e.g., consumer of P1 is A or B), platform (e.g., RAM is present or not) or mapping (e.g., D1 can be stored in ROM or RAM) gives rise to an optional feature in the PFM. The attributes representing design variations (e.g. the size of D2) are transformed into alternative features, while those representing quality attributes (e.g. cost of manufacturing) become the PFM's quality attributes. Ψ ρ results directly from the mapping rules (3a and 3b), the presence conditions Θ between resources (5), consistency rules requiring that alternative application node or optional resources used in the mapping become mandatory (1,2,4), and constraints over attribute values encoded in χ d and χ r . Ψ τ correspond to the NF requirements defined by the engineers. Finally, η is obtained from χ d and χ r .

To check requirements that depend on behaviour, we need to systematically evaluate all executions of all design variants. A common approach to achieve this for a single design is to model-check an automaton modelling the system behaviour [START_REF] Bengtsson | Uppaala tool suite for automatic verification of real-time systems[END_REF], [START_REF] Clarke | Model checking[END_REF], which results from the scheduling [START_REF] Dalsgaard | Metamoc: Modular execution time analysis using model checking[END_REF] of an application automaton on a platform automaton. These approaches, however, cannot handle variability and are thus limited to one system at a time. Accordingly, we propose to generate, from our variability-intensive design space, a Featured Weighted Automaton (FWA) [START_REF] Fahrenberg | Featured weighted automata[END_REF] -a recent formalism that combines featured transition systems [START_REF] Classen | Featured transition systems: Foundations for verifying variability-intensive systems and their application to ltl model checking[END_REF] with priced automata [START_REF] Droste | Handbook of Weighted Automata[END_REF]. Basically, FWA is a variability-aware, weighted extension of finite state machines where each transition t is annotated with a formula defining (i) which variants can execute t; and (ii) conditional weight values that depend on the variant executing t. This formula, named weighted feature Fig. 5: An excerpt of the PFM corresponding to Fig. 2 and3.

expression, allows one to represent compactly the evolution of quality attributes as the execution of the variants progresses.

Definition 4: Let F be a set of features and {τ 1 . . . τ n } an ordered set of n positive real-valued weights. Then a weighted feature expression is a (possibly partial) function γ : 2 F → R n ≥0 that associates a variant F ⊆ F with a vector w such that w i is the value of the i-th weight for F .

Intuitively, the weighted feature expression γ associated to a given transition t is such that a variant F belongs to dom(γ) if and only if F can execute t, and γ(t) returns the value of t's weights for F . In our case, each weight corresponds to a distinct quality attribute and represents the value added to this attribute when F executes the transition t.

Definition 5: Let T = {τ 1 . . . τ n } be a set of positive realvalued, quality attributes and pf m = (F, Q, Ψ ρ , η, Ψ τ ) be a PFM, such that Q ⊆ T . A FWA over T and pf m is a tuple f wa = (S, s 0 , s f , T, γ → ) where S is a set of states, s 0 is the initial state, s f is the final state, T ⊆ S × S is the transition relation, and γ → : T → 2 F → R n ≥0 associates each transition with a weighted feature expression.

A FWA defines, for each variant F ⊆ F , the set of paths starting from s 0 to s f that F can execute, together with the weight vector associated to each path: ∀F ⊆ F : f wa (F ) = {(p, w) ∈ S + × R n ≥0 } where p = s 0 → • • • → s k = s f and such that (i) p exists in f wa: ∀j : 0 ≤ j < k : (s j , s j+1 ) ∈ T ; (ii) all transitions of p are executable by F : F ∈ k-1 j=0 dom(γ → (s j , s j+1 )); (iii) w is the sum over all associated weight vectors: w = Σ k-1 j=0 γ → (s j , s j+1 ). Note that we assume all quality attribute values to be positive. Negative values are supported modulo transformation. In PFM, one can replace negative values on a feature by positive values on the alternative features. In FWA, one can replace negative values on a transition by positive values on the alternative transitions.

From the design space, we generate a network of FWA, where each source datum, task, processor and memory storage corresponds to a distinct FWA whose states and transitions encode the different steps of their process. Data automata implement the process of sending the data onto a task automaton, which itself transmits the data to the automaton of the processor that provides the function whereon the task Fig. 6: An FWA modelling memory storage behaviour. is mapped. The automaton of a processor models standard processing pipeline behaviour [START_REF] Lazreg | Assessing the functional feasibility of variability-intensive data flow-oriented systems[END_REF]. During this processing, the processor can store input and output data by transferring them to its dedicated storage automaton.

An excerpt of FWA modelling storage behaviour is shown in Fig. 6. It models memory read and write via input/output interfaces while checking that memory capacity is never exceeded. Weighted feature expressions occur in the transitions of the hardware resources automata (i.e. processors and memories) that correspond to processing instructions and memory accesses, as these operations impact the "execution time" quality attribute. In the excerpt, such an expression is shown in pink and models that the increase of time depends on RAM frequency. The automaton modelling all the designs results from the parallel composition of the individual automata, which can synchronize their transitions on specific synchronization actions (e.g. the transfer action in Fig. 6 sends data only when another FWA executes the corresponding action).

Our FWA differs from that of Fahrenberg et al. [START_REF] Fahrenberg | Featured weighted automata[END_REF]: (i) ours is linked to a PFM to also check structural requirements;

(ii) we support parallel composition and consider time as a special weight in that we execute fastest actions first and dynamically update the remaining time delay of other parallel actions to simulate time elapsing; (iii) Fahrenberg et al. [START_REF] Fahrenberg | Featured weighted automata[END_REF] represents γ → as a partition of the set of variants because their verification algorithm -which is not tooled -relies on matrix representations, whereas ours relies on antichains [START_REF] Comtet | Sperner Systems (7.2)[END_REF] to scale wrt. the large state space incurred by our evaluation cases.

VII. ALL-IN-ONE VERIFICATION AND OPTIMIZATION

Our FWA formalism allows us to design a first algorithm to solve all challenges FCS, FCB, NFS and NFS for all variants at once. The key idea is to perform an exploration of the state space of the automaton in search of paths that can reach the final state while satisfying the FC and NF requirements.

The first step filters out variants that do not satisfy PFM constraints Ψ ρ and Ψ τ , thereby ensuring that the structure of the variants does not violate the requirements. Then we explore all paths starting from the initial state. As we visit a new state, we retain the set of variants able to execute the sequence of transitions that led to the state. We also accumulate the sum of the weights over all executed transitions and for all variants and assert that these values satisfy the NF requirements. In the end, we obtain a set of paths going from the initial to the final state, together with, for each path p, (a) the valid variants that can execute p and (b) the values of the quality attributes corresponding to p and each of those variants.

This first algorithm finds all variants satisfying the requirements. We have to find what are the optimal variants satisfying the requirements while providing the best values for the quality attributes. Since these attributes can be antagonistic (e.g., manufacturing costs can decrease to the detriment of rendering quality), this is assimilated to multi-objective optimization. To drive our search for optima, we define a cost function over the attributes: let ζ(τ 1 , . . . , τ n ) = θ 1 × τ 1 . . . θ n × τ n be our cost function, such that θ i ∈ R + is the coefficient associated to the attribute τ i . Then, our objective is to discover the variant that minimizes ζ. This is achieved by modifying our exploration algorithm in order to (i) record the optimal variants and their associated attribute values, and (ii) stop exploring a path as soon as all quality attributes reach a worse (i.e. higher) value. This latter heuristics requires the cost function to be monotonic as more states are explored along a given path; hence why we assume that all θ i and τ i are ≥ 0. Negative values can be supported by disabling the heuristics (Line 7 in Algorithm 1).

Algorithm 1 details this exploration procedure. It takes as input a FWA, a PFM and a cost function ζ. It iteratively computes R, the reachability relation that associates each state s to the γ function encoding all variants that can reach s and their associated attribute values. At first (Line 1), R contains s 0 together with γ 0 , such that dom(γ 0 ) = dom( pf m ) and γ 0 (F , τ i ) = 0 for any variant F and attribute τ i . Then, we start the exploration from s 0 (L3-4) and iterate over the states encountered successively (L5-20). At each iteration, we retrieve the state s reached last, together with its associated γ function (L6). Here, γ encodes the variants that can reach s and associates to each variant the values of its attribute values when following the path that led to s. If all these variants yield a value for ζ greater than the current optimum ζ * (L7), we do not pursue the exploration further from this state. Otherwise, we distinguish between the cases where s is s f (L8-10) and where it is not (L11-18). In the first case, we assign ζ * to the minimal cost over all variants that can reach the final state. In the second case, we compute the set of successors of (s, γ)

Input: f wa = (S, s 0 , s f , →, γ → ); pf m = (F, Q, Ψ ρ , η, Ψ τ ); ζ : ζ(τ 1 , . . . , τ n ) ∈ R + Output: F * , the set of optimal variants that reach s f ζ * , their associated minimal cost 1 R ← {(s 0 , γ 0 )}; 2 ζ * ← +∞; 3 Stack ← []; 4 push({s 0 , γ 0 }, Stack); 5 while Stack = [] do 6 (s, γ) ← pop(Stack); 7 if ∃F ∈ dom(γ) : ζ(γ(F )) ≤ ζ * then 8 if s = s f then 9 ζ * ← min F ∈dom(γ) ζ(γ(F ));
F * ← {F * ⊆ F |(s f , γ f ) ∈ R ∧ γ f (F * ) = ζ * }; 22 return (F * , ζ * ) Algorithm 1: optima(f wa, pf m, ζ) (L12), given by P ost(s, γ) = {(s , γ )|(s, s ) ∈ T ∧ γ = γ ⊗ γ → (s, s )} where dom(γ 1 ⊗ γ 2 ) = dom(γ 1 ) ∩ dom(γ 2 ) and ∀F ∈ dom(γ 1 ⊗ γ 2 ) : (γ 1 ⊗ γ 2 )(F ) = γ 1 (F ) + γ 2 (F ).
This means that γ is defined only for the variants that can reach s and execute the transition from s to s , and it sums the attribute values of each variant in γ with its attribute values on the transition (s, s ). Then, we add a successor iff it improves the reachability relation (L13), that is, if for at least one variant, there is no element in R that gives a better value for all attributes. This rule ensures that infinite cycles are avoided. To do so, we use the comparison operator over weighted feature expressions, defined as γ 1 γ 2 ≡ ∀F ∈ dom(γ 1 ) : γ 1 (F ) ≥ γ 2 (F ). If R is improved, we continue the exploration (L14) and add the successor to R (L15) using a particular union operator that keeps R as an antichain. This is achieved by a split-and-combine algorithm along the lines of [START_REF] Cordy | Behavioural modelling and verification of real-time software product lines[END_REF], [START_REF] Fahrenberg | Featured weighted automata[END_REF], which we do not detail due to lack of space. Finally, we return the set of variants F * that can reach s f while minimizing ζ, together with the optimal cost (L21-22).

VIII. IMPLEMENTATION AND EVALUATION

A. Implementation

We implemented our framework as a toolchain combining a new Java tool with (extensions of) existing model checkers.

Our Java tool1 consists of two modules, each of which implements a process depicted in Fig. 4. The first one allows for specifying a variable data-flow graph and a variable resource graph via a fluent API. Then, it calls our mapping algorithm to generate the design space. Second, an automata generator takes as inputs the design space, NF requirements and the cost function to generate an FWA with its associated PFM. Two concrete syntaxes are used, as we can then invoke two independent model checkers to search for optima.

One is UPPAAL-CORA [START_REF] Behrmann | Optimal scheduling using priced timed automata[END_REF], an established tool to carry out cost-optimal reachability analyses that we reuse as is with optimal settings. It takes as input a network of Linearly Priced Timed Automata (LPTA) [START_REF] Behrmann | Minimum-cost reachability for priced timed automata[END_REF]. LPTA can be regarded as FWA without variability, and as such can only encode the behaviour of the variants separately. Our automata generator actually transforms our design space into a network of LPTA in the UPPAAL-CORA format. It also generates an additional automaton dedicated to configuring the other LPTAs before their execution starts, by setting variables that correspond to the variation points of the design space. We thus follow the 150% model approach [START_REF] Thüm | A classification and survey of analysis strategies for software product lines[END_REF]. Additionally we use SPLOT's feature model reasoning library [START_REF] Mendonca | Splot: software product lines online tools[END_REF] to restrict the configuration to valid products. Then, UPPAAL-CORA can find an execution of a variant that reaches the accepting state while satisfying all the NF requirements and optimizing the cost function.

The other model checker is ProVeLines [START_REF] Cordy | Provelines: a product line of verifiers for software product lines[END_REF], which can check variability-intensive systems. We chose this tool because it was extended over the years, by both its original developers [START_REF] Cordy | Provelines: a product line of verifiers for software product lines[END_REF] and others [START_REF] Olaechea | Long-term average cost in featured transition systems[END_REF], [START_REF] Olaechea | Trace checking for dynamic software product lines[END_REF], to solve multiple modelchecking problems including real-time verification [START_REF] Cordy | Behavioural modelling and verification of real-time software product lines[END_REF]. We fully implemented Alg. 1 in a new version of ProVeLines. 2 To achieve this, we first extended ProVeLines' input language -Promela [START_REF] Holzmann | The SPIN Model Checker: Primer and Reference Manual[END_REF] -to associate Promela statements with weighted feature expressions. Actually, each Promela process encodes a single FWA. Like UPPAAL-CORA, our ProVeLines extension is able to provide the execution trace associated to an optimal variant. The difference lies in that weighted feature expressions allow an all-at-once verification of all variants. To encode the structural variability, we generate a PFM in the format supported by ProVeLines, viz. TVL [START_REF] Cordy | Beyond boolean product-line model checking: Dealing with feature attributes and multifeatures[END_REF], [START_REF] Classen | A text-based approach to feature modelling: Syntax and semantics of tvl[END_REF].

B. Qualitative Evaluation

Our first evaluation assesses the usefulness of our approach for practitioners on the basis of Visteon's instrument cluster system (see Sec. II). More precisely, our evaluation concerns an important module of the whole system. Yet, it remains a real-world case that was selected by our partner as representative in terms of size, complexity and variability.

With the assistance of an expert engineer, we reversemodelled the variable application and platform of the existing system. Some technical simplifications were made as we aim at facilitating early design decisions: we do not consider data and parameters that only have minor impact on the system's runtime; we abstract away from data content and consider data sizes as the most influential factor for runtime performance; we do not model mechanisms like internal cache replacement policies, AXI bus and internal backup communication buffers as these implementation details have no fundamental impacts and are handled by engineers later in the development process. These simplifications were deemed harmless by our industrial expert and did not endanger the correctness of our results.

This results in an application model with two input data types, four tasks and 32 flow processing, and in a platform model with one ROM, one RAM, one DCU and two GPUs. In total, the variability yields 1,548,288 candidate designs. Our generated mapping rules reduced this number to 1,878. By adding the NF requirements rendering quality ≥ 2 and manufacturing cost ≤ 280, we further diminish this number to 894. By checking the behaviour against the requirements (i.e. the end of execution is reached within 840 processing cycles) we obtain 279 variants that satisfy all requirements. Incorporating the cost function representing trade-offs defined with the expert (i.e. with θ time = 1, θ m.cost = 10, θ r.qual. = 100) yielded 6 optimal variants with time = 642, manufacturing cost = 140 and rendering quality = 2.

We performed the behavioural analyses using both UPPAAL-CORA and ProVeLines, which provided the same results for all variants. This increases our confidence that the transformation of the design space into LPTA and Promela is consistent. Expert's confirmation is also needed, though, as mistakes may originate from the input models themselves. The expert validated that the optima returned by our tools conform to the very best designs that the company could produce over the past years. The quality attributes' values also corresponded to what is expected. Regarding execution time (cycles), there are slight differences due to hardware modelling simplifications; however, the numbers are close to reality (< 10% difference) and the relative orders between variants are preserved. In the end, the expert validated that our approach helps make optimal design decisions that will provide significant gains at all stages of development.

C. Quantitative Evaluations

The second part of our evaluation focuses on the efficiency and the scalability of our approach in terms of execution time. This is indeed essential, as the total number of variants can be high in real-world systems. In addition to the instrument cluster case study (numbered case #0), we constituted a dataset of realistic topologies that were generated based on our partner's history. To do so, our model generator relies on multivariate Gaussian distributions whose parameters were settled on the basis of Visteon's past systems. Thereby, it ensures that the characteristics of our generated data-flow and platform models are similar to real-world cases. Amongst all the models we generated, we selected 11 of them that appropriately summarize our findings. These models exhibit different state densities (i.e. average number of system states per variant) and variability intensities (i.e. numbers of valid variants to check). We carried out three series of experiments Product-based vs. family-based. Our first experiments evaluate the efficiency of our method to verify that all variants satisfy the requirements, that is, we consider only the four challenges FCS, FCB, NFS and NFB. We compare the runtime of our family-based verification algorithm with an alternative, product-based one that checks each variant separately. Both algorithms are implemented in ProVeLines, which allows us to compare both approaches on an equal technological ground.

The results are presented on the left part of Table I. It depicts, for each approach and model, the time needed to check all variants as well as the total number of states that were explored by each algorithm. In the family-based case, fewer states are explored since one state common to multiple variants is explored only once. For case #0, the family-based method outperforms the product-based one, reducing the verification time from 22.60 seconds to 3.33. The generated models allow us to observe that the benefits of the family-based method grow with the number of variants. When this number is low (#1-3), our family-based algorithm either brings insignificant improvements (#1 and #2) or performs way worse than the product-based approach (#3). On the contrary, for models with higher variability (#4-11) we obtain reductions in verification time of minimum 16% (#6), most often substantial ones. The most impressive results are obtained for the case with the most variants (#11 -which is also the case where variants share the most commonalities): our algorithm is 5.9 times faster, achieving an absolute reduction of 1,116.92 seconds. We also see that a higher state density often reduces the gain offered by our algorithm (e.g. cases #5 and #7). To explain this, we analyzed the models and observed that a small number of variants exhibit a large state space, while all the others encompass far fewer states. The variants thus have fewer states in common, while family-based algorithms generally perform better as variants share more commonalities. This also explains the poor performance of our algorithm in case #3.

Optimization in ProVeLines and UPPAAL-CORA. Our second experiment compares the efficiency of the two model checkers to solve challenge NFOB, that is, we compare UPPAAL-CORA cost-optimal reachability algorithm against our Algorithm 1. The two tools present clear differences, notably in history (UPPAAL-CORA's development started in the early 2000's, while ProVeLines was released in 2013), in focus (cost-optimal reachability in continuous-time models vs. family-based model checking in discrete-time models) and in input syntax (LPTA vs. Promela). Still, we believe this comparison can highlight interesting research directions.

Results are given at the centre of Table I. Like any productby-product approach, UPPAAL-CORA suffers from every increase in the number of variants, except for cases #4 and #6 where it luckily alleviates complexity with branch-andbound optimizations. It systematically performs poorer than ProVeLines. Even worse, apart from cases #0-2, #4 and #5, UPPAAL-CORA consumes too much memory (> 16GB) and raises a fatal error. We assumed two reasons behind this. First, UPPAAL-CORA does not implement partial-order reduction [START_REF] Godefroid | Partial-Order Methods for the Verification of Concurrent Systems -An Approach to the State-Explosion Problem[END_REF] and thus considers all possible interleavings between LPTAs, including during their configuration. This creates an exponential blow-up as the number of LPTAs increases. Second, we use a model that encodes the behaviour of all variants and thus accumulates all their state space. Yet, applying an alternative, product-based approach where each variant is turned into a separate model did not solve the problem and even led to slower times. Process interleaving is therefore responsible. One way to circumvent this is to assign priorities over the automata. However, in most cases, this will cause to miss better scheduling opportunities and will yield suboptimal results. In spite of the disappointing results for UPPAAL-CORA, the fact that it outperforms productbased ProVeLines on case #0 tends to indicate that combining our family-based algorithm with UPPAAL-CORA's efficient search heuristics can be a promising future work.

Through these experiments, we also observe that looking only for optima in ProVeLines, as opposed to verifying all variants, can yield significant reductions in execution time (up to 68% in case #11). More importantly, computing the optima without a family-based algorithm boils down to applying the product-based algorithm used in the first series of experiments. In this regard, our Algorithm 1 exacerbates the benefits of a family-based algorithm. For the models with the most variants (#9-11), Algorithm 1 is 5 to 128 times faster than the productbased method. Interestingly, it seems to be way less affected by the number of variants than the all-variant verifications.

Prioritization based on structural optima. The last part of our evaluation studies whether the structural optima (i.e. the solutions of NFOS) are sufficiently close to the overall optima (i.e. the solutions of NFOB). If that is the case, solving NFOS would yield an imperfect but relevant, cost-effective solution, as structural optimality can be resolved statically, that is, without requiring the exploration of a large state space. We use the ClaferMOO tool [START_REF] Olaechea | Modelling and multi-objective optimization of quality attributes in variability-rich software[END_REF], [START_REF] Murashkin | Visualization and exploration of optimal variants in product line engineering[END_REF] to compute the structural optima based on our PFMs. To complete the toolchain, we extended it to generate PFMs in ClaferMOO's format, as well as our verifier module to retrieve the variants that are structural optima and only allow these variants by adding a constraint in the PFM. Then, we use ProVeLines in family-based mode to assess the time needed to discover which structural optima lead to the lowest cost function value, as well as the difference between this value and that of the overall optimum.

Results are given on the right side of Table I. The first two columns give the number of structural optima returned by ClaferMOO, as well as the time needed to run ProVeLines only on those structural optima. The last column gives the increase of cost function, in percentage, due to considering only structural optima instead of all variants. In cases #1-3, #5 and #7, the variants differ only by their behaviour and are thus all structural optima. For the other cases, we see that ProVeLines' runtime is dramatically decreased as it has to check fewer variants. This, however, comes at the cost of a notable increase in cost function value (up to 96%), except for case #8 where it increases by less than 2%. We conclude that structural optima are still far from being overall optima, and thus are not sufficient. Yet, in some cases they can constitute viable solutions to get a quick answer or when the state space of the system is too large to be exhaustively explored.

D. Threats to Validity

Internal. The main threat to internal validity is the selection of the used case study. Although it was built from specification and feedback meetings with system and platform experts from our partner company, it is a single case. Still, Visteon chose it as being representative in terms of shape and complexity of the data flow, the platform and their variability.

External. Several threats to external validity exist. First, our scalability experiments have been conducted over large but simulated data sets. We nevertheless expect the creation procedures to respect the structure and behaviour of the potential applications and platforms of our industrial partner. More generally, we also expect the proposed approach to be applicable in other domains where data flows can be an appropriate modelling support, like stateless enterprise processes with micro-services. On the platform side, the componentbased representation seems general enough to cover different forms of deployment architectures, but we do not have any evidence yet of this generalization possibility.

Second, satisfiability and optimality checking processes depend highly on the level of detail and on the quality of application and platform modelling. On the platform side, a design not detailed enough could lead to loss of relevance in the performance metrics, and could even produce false optimal results. From the feedback we got from our industrial partner, the level of detail is currently sufficient as it is at the level they use to specify the platform when selecting suppliers. Still, in other contexts, some details may be hidden due to intellectual property management. As for applications, they are described with data-flows that are well mastered by domain experts in our case study, but they have been built manually. Reverse engineering from existing application code could be envisaged to build data-flow or at least templates of them, but their quality would be directly related to the good organization of existing software. More globally, as the engineers were able to understand proposed designs that result from our framework, machine learning technique fed by their feedback on good or bad solutions could help when details are missing. Introducing this in the framework remains an open issue.

IX. CONCLUSION

In many data-flow oriented embedded systems, three levels of variability significantly increase the complexity of the design space: variable high-level data-flows are deployed in many different ways over highly configurable componentbased hardware platforms. We provided a modelling and reasoning framework that unifies state-of-the-art techniques on structural reasoning with a novel variability-aware modelchecking algorithm, which evaluates the functional feasibility, the non-functional satisfiability and optimality on the whole design space. This design space comes as a mapping between two other models: one represents the variable applications with a data-flow model complemented with quality attributes, the other models platform variability through connected components, also with quality attributes. We showed how the design space is transformed into featured priced timed automata to enable different reasoning and optimization operations.

The application of the proposed approach to a medium-scale industrial case of an automotive instrument cluster demonstrates its end-to-end ability to check and optimize a complex design space. System experts revealed that, even on small data flow and platform models, the optimal designs were non-trivial to identify for them, giving us confidence on the relevance of the approach. Experiments on large simulated design spaces also show that the prototyped toolchain exhibits good scalability and outperforms non-variability-aware solutions.

We believe that the models used in the framework (dataflows and components) make the contribution potentially applicable in different contexts. Our future works will start with an extension of the framework to facilitate its usage, introducing domain-specific languages for input models. We also plan to conduct larger evaluations on different data flows coming from various product lines of our industry partners.

Fig. 1 :Fig. 2 :

 12 Fig. 1: Our instrument cluster application case study

Fig. 4 :

 4 Fig. 4: Framework Models and Processes

15 R

 15 , γ ) ∈ P ost(s, γ) do 13 if ∃(s , γ ) ∈ R : γ γ then 14 push((s , γ ), Stack); ← R {(s , γ )};

TABLE I :

 I Results for the three quantitative evaluations. Times are in seconds. TableIprovides the results, such that the results of the different series of experiments are separated by double borders. All benchmarks were run on a MacBook Pro 2014 with a 2,8 GHz Intel Core i7 processor and 16 GB of DDR3 RAM. We repeated each experiment ten times and computed the average, although random deviations were low.

				(1) FCS + FCB + NFS + NFB	(2) NFOB	(3) NFOS Priorization
				Product-based	Family-based	P.V.L. optim	UPP.-CORA	ClaferMOO + P.V.L.
	case density	variants	time	explored	time	explored	time	time	time	# OOS	inc. %
	Ins. Cl. (#0)	369	1,878	22.60	693,178	3.33	305,114	2.42	5.64	0.08	10	74.10%
	Gen. #1	1,561	32	0.80	49,952	0.48	45,681	0.38	18.61	=	=	=
	Gen. #2	2,250	64	2.72	143.968	2.10	124,004	1.27	39.59	=	=	=
	Gen. #3	3,061	243	22.11	743,823	80.54	660,348	75.79	OoM.	=	=	=
	Gen. #4	1,656	516	16.32	854,996	10.95	777,616	8.23	17.60	2.32	129	9.19%
	Gen. #5	2,256	1,152	55.48	2,599,393	40.17	2,217,593	29.77	OoM.	=	=	=
	Gen. #6	1,496	1,280	38.49	1,915,264	11.81	840,711	8.65	19.89	1.37	64	40.86%
	Gen. #7	2,416	2,187	144.48	5,283,792	120.83	4,593,249	89.56	OoM.	=	=	=
	Gen. #8	1,461	2,592	109.96	3,785,940	35.01	1,032,639	24.40	OoM.	17.60	324	1.39%
	Gen. #9	2,273	3,168	151.87	7,201,320	69.14	3,926,395	19.58	OoM.	6.21	792	9.81%
	Gen. #10	1,609	12,288	395.64 19,777,536	148.71	6,570,642	75.97	OoM.	3.62	256	64,90%
	Gen. #11	1,732	34,560	1344.23 59,858,304	227.31 10,871,741	72.17	OoM.	2.90	32	95.77%
	presented hereunder.

https://bitbucket.org/SamiLazreg/enlighter

https://bitbucket.org/maxcordy/provelines-cora


Reviewed by Peter Marquis

In, Le Football dans Paris et ses banlieues, an historical exploration of the development of soccer in Paris and its suburbs (in French "les banlieues") from the 1890s to the 1940s, Julien Sorez sets out to answer key questions related to French social history and the global history of the world's most popular sport. First, Sorez scrutinizes the centrality of soccer in the French national context given that the capital has always been viewed as the centre of legitimate cultural practices such as the theatre and the opera. Second, he wonders why Parisian soccer took a secondary role in the interwar years when the game began to commercialize and yield profits nationally. Third, Sorez ponders whether soccer sociability enabled a set of like-minded professionals to strengthen and duplicate their socio-economic ties or if the practice paved the way for a "reconfiguration of the social world creating new links through associations" (p. 20). In chapters three and four -gathered around the title "territories" -Sorez traces the gradual spatial legitimization of soccer in Paris and its suburbs. He argues that from the end of the 19th century to the 1920s, soccer was badly considered so that it was played at the margins of the cities, often on vacant lots or at the edge of woods. Yet its imaginary territory was made real by the mindset of the players were who resilient enough to build plaques, move goal posts and to create cafes (bistrots) through which their existence was made real in the minds of those engaged.

Thanks to his deft use of archives from

Home

This drastically changed after the First World War when municipalities tapped into the potential of the soccer craze to establish political clout through the building of municipal stadiums. The author shows how politicization impacted elections and facilitated social control over soccer players. Two types of control existed, one through rules and regulations implying proper behavior and sanctions, the other -internalized -which replicated onto the sporting arena the discipline brought forth by the paternalistic factory.

Sorez devotes chapters 5 and 6 to the question of identities and social bonding. He makes a compelling case that soccer in and around Paris asserted values such as masculinity. Indeed women were strictly banned from the practice and the social rituals around soccer. Clerical professions made up 23% of the 115 players that the author managed to socially identify. He also makes the case that soccer was surrounded by rituals such as the journey to play away and the inevitable visits to the drinking house. In the interwar years soccer took on a different social role as it became less family oriented and dovetailed with the values of the new individualistic age; however the government and athletic associations strove to instrumentalize soccer to train the French youth into patriotic citizens. Sorez quotes the mainstream press which harped on the theme of the "family spirit" of the soccer club to combat selfish attitudes which would endanger the nation (p.

265).

The last part is devoted to the social legitimatization at soccer because the sport grew from a British marginalized practice for men of similar social and professional backgrounds to a mass sport played nationwide which took on several social meanings including what constitutes proper behavior. Sorez analyzes acts of violence and social disorder through a critical framework because he questions the use of the word "violence" then as opposed to today's standards. In these pages he other proves a fine writer using the thick description of games and off the lines attitudes based on primary and secondary sources.

To him, soccer represented a school of masculinity both for the players and the audience;

he analyzes the chants in the stands; however he warns the reader that the available documentation is too slim to make definite interpretations.

In the eighth and last chapter the author devotes very interesting pages to the transformation of soccer into a spectacular activity, a show that was both commercial visual and social. He first analyzes the creation of the soccer star through the mainstream press that focused mostly on the style of living of the player more than on his playing style.

Stress was laid on the players' day jobs as bakers or grocers to silence the fears of those Furthermore, soccer in and around Paris became a legitimate social outing based on the creation of paying entrance to stadiums where an average of 4,000 people attended season games (p. 358). But unlike drama or the opera which favored silence, discipline of the body and emotions, downplaying of the interaction between musicians actors and the audience, soccer allowed the spectators a more open behavior, or even to voice their discontent, enthusiasm and demands for good quality in exchange for the money paid.

The author uses a few newspaper sources to argue that spectators belonged to various social classes and were unevenly distributed in the stands: the most expensive seats along the centre of the stadium were occupied by middle classes and bourgeois people, whereas the stands -seats behind the goal posts -were for the populace.

Overall, Le Football dans Paris et ses banlieues is very effective in showing the evolution of Parisian soccer from a socially segregated informal pastime to a nationwide commercial endeavor cutting across various social classes. But Sorez's analyses go beyond the legitimization thesis as he delves into the details of metropolitan politics, interactions between the press and elite, and the advent of group identities anchored in spaces in rituals (Halbwachs). Thanks to a rich array of sources, the author manages to make the compelling case that in order to understand the rise of soccer in and around Paris, one has to acknowledge its "plasticity which allows for a differentiated and diversified appropriation by the social agents, which testifies of the social emulation on which the sport could rely to flourish" (p. 378).

Sorez's approach and conclusions echo those of other scholars of early 20 century and interwar sports, especially Riess (1999) and Marquis (2009) on baseball in the American city. However, one aspect which seems to be lacking in Sorez's otherwise very complete study is gambling. Was it officially banned? If there was tolerance, who derived profit from it? When money is involved, spectators tend to develop a sense of excitement and belonging to the local team that transcends social and spatial rituals. How did this play out in and around Paris both before and after the First World War?

  . Le Football dans Paris et ses banlieues : un sport devenu spectacle. Rennes: Presses universitaires de Rennes, 2013. 410 pages. Notes, index, illustrations, appendices. 22 euros. Print.

  root in the Parisian area. Also, the writer shows that Parisian clubs frequently moved from one playing ground to the next in a nomadic way hardly conducive to creating long lasting identifications between the population and their environment. Finally, political actors failed to capitalize on soccer's social prestige as they were vying for recognition and resources within the Paris metropolitan area.Nevertheless, Sorez asserts that soccer was one of the main levers to a form a suburban identity for working class people, mostly young men coming from the province or from overseas. As the 1930s wore on, soccer grew out of its initial anglophile fan base to reach out to popular classes thanks to the process of social legitimization of sport as a greater good in addition to classic forces such as school or the family. Reports in the mainstream press praised the feats of heroes, both manly and respectable. Prominent local figures attempted to exert social control over their constituencies through organizing soccer clubs, but Sorez cautiously notes that players and spectators asserted their agency to oppose preferred models of admiration and behavior.Sorez concludes that the success of Parisian soccer in the 1930s was due to its capacity "to adapt to a universe of contemporary representations and (…) dominant values of its times" (p. 376). Like Van Bottenburg, Sorez steers clear from a formalistic explanation of soccer's appeal, as he demonstrates that the sport took on several social meanings depending on the individuals, the place, the social standing, or the strategies at work.Of particular interest to this reviewer was chapter one where Sorez shows the British origins of Parisian soccer both in terms of the initial players who were mostly British students in Paris or French students who took a year abroad in the British Isles and practiced soccer in their high school when they came back. The British tutelage was also present in the executive organization of the first Parisian clubs such as the Standard Athletic Club, the Red Star (founded by Jules Rimet), the white Rovers or even the Club Français. Sorez shows with great skills in analyzing microscopic archives that the British role both energized competition, improved the level of play (through the prevalence of the pass for example) while on the other hand impeding the social legitimization of soccer within the established athletic institutions such as the USFSA to which soccer conveyed amateur, socially dangerous, working class values.

  Review of Le Football dans Paris et ses banlieues | Sport in Ameri... https://ussporthistory.com/2018/07/21/review-of-le-football-dans-p... to pure amateurism. But in the 1930s being a full-time soccer player became a legitimate occupation as illustrated by the career of Raoul Diagne, son of Senegalese house member who decided to become a player whereas he could have gone on to be a lawyer or doctor (p. 347).

	3 sur 11	08/03/2019 à 00:41

attached

  Peter Marquis is Associate Professor of US history at the Université de Rouen (France). A specialist of sports and urban history, he contributed to P. Peretz, ed. New York: histoire, promenades, anthologie et dictionnaire (Paris: Robert Laffont, 2009) and edited "Sports in American Society"(Transatlantica, 2012). His latest publications have focused on US sports in France during WWI, sports and the American presidency, and the place of baseball in US popular culture. He is currently working on spectatorship and masculinities, as well as on pedagogy. Follow him on twitter @sportetsocietes.

								th
	Share this:
		Twitter		Facebook		Email		Print

08/03/2019 à 00:41