Functionally Safe Multi-Core Systems

Georg von der Brüggen
Ian Gray

There is a significant problem on the horizon in the field of embedded and real-time systems. The traditional approach for certifying high-integrity systems is no longer possible due to the increased complexity of modern applications, and the hardware platforms on which they execute are becoming heterogeneous multi-core systems on chip.

Considering how functional safety can be provided for multi-core systems, this Dagstuhl Seminar aimed to bring together experts from both academic and industry as well as participants from the three relevant layers, namely, application, middleware, and platform. The goal was to look at these topics from the individual perspective and to inspire interesting and fruitful discussion.

The purpose of the introductory sessions was to explain the way in which the seminar was being arranged and focus on the idea that the participants can decide what the outcomes should be, and the sessions that therefore should be scheduled in order to make that happen. The introduction was led by Ian Gray from the University of York. This session explained the background to the original Dagstuhl proposal, which is that critical systems based on multicore processes are an inevitability. Very few OEMs design and build their own processors, and there are very few single-core processors that can be purchased with a supply guarantee for over 20 years – the sort of guarantee that would be required in many industrial systems. Therefore, these new multicourse systems must be used, and must be made safe.

The seminar participants were chosen from three main areas:

• $\mathrm{■}$

  Industry

• $\mathrm{■}$

  Academic

• $\mathrm{■}$

  Junior researchers

Unlike many similar seminars in which the audience is academic with industrial representation, we aimed for a much more even split. Problems and difficulties in this area are encountered from both the theoretical and from the practical side, and so input from both areas was vital. Equally, we ensured that new researchers were also represented to capture a wide range of academic thought. The participants were selected across the Americas, Europe, and Asia, and we encouraged leadership and representatives who identify as genders other than male.

The introductory session contextualised some of the work that has already been done by the certification authorities toward functional safety in multicore architectures. Particularly CAST-32A, which became AMC 20-193, that codifies:

• $\mathrm{■}$

  Measurement-based approaches to timing analysis can only deliver approximate knowledge of a system’s timing properties.

• $\mathrm{■}$

  Knowledge has uncertainties (known and unknown).

• $\mathrm{■}$

  There may be extreme behaviour that has not been seen.

• $\mathrm{■}$

  Static analysis approaches make an assumption that valid knowledge is available for all hardware and software, and that there are no anomalies.

This means any design and assurance may need to be stochastic in nature allowing for questionable confidence measures and significant uncertainties. Indeed, the balance between stochastic assurance and proof-based assurance remained an important topic of discussion throughout the entire seminar.

The introductory session used live audience polling technologies to determine the feeling of the room and to start to collect information that would be used to design upcoming sessions. The question was asked “To what extent do we think exact analysis for these systems is still possible?”. As can be seen from the results in Figure 1, a wide range of views were held by the participants. This ranged from a complete rejection of the feasibility of exact analysis, through some level of stochastic analysis, to a few believers that exact analysis will always be mandatory.

The second section of the day attempted to break down the singular problem of functionally safe multicore systems into a range of levels at which the issues can be defined and solved. The organisers deemed that these levels were “application”, “middleware”, and “platform”, and so, this section sought to define these layers and solicit beliefs about the biggest challenges at each level.

After the previous session focused on the perspectives of applications, middleware, and platforms, the two final sessions on Monday started by collecting the thoughts of the participants on the properties needed and the functionalities that must be provided to allow verification.

Observability was determined as a key factor – otherwise, a system may be functionally safe but the safety cannot actually be argued and verified. However, it is not clear how observability can be achieved in practice, especially when abstractions need to cross layers. As a result, model composability is challenging, and if not appropriately scoped, impossible.

It was also mentioned that partitioning on the hardware level may be better than software partitioning due to potential overhead and granularity. However, while this may be an approach for static applications, it may not work well if applications have more dynamic needs. It was also pointed out that partitioning is not always possible – for instance, parallelization is often necessary but avoiding race conditions is non-trivial.

Research on multi-core systems will rely on results in other areas. However, these results may either not be known or assumptions and details may be unclear for people who are not experts in the field. For instance, it was (to the participants) unclear what the status of research into stochastic modeling of network traffic is. In this context, it has been pointed out that incorrect analyses had previously been used in practice, but that the overall over-approximations were still sufficiently pessimistic to prevent errors from occurring in practice. This was seen as an argument for a composable analysis compared to a holistic analysis.

An alternative approach could be to flip the problem – by imposing constraints on software development and preventing worst-case overlaps. For instance, some real-time operating systems do not impose constraints while others require applications to follow a given partition scheme.

This approach could play out in a way that industry is given a list of constraints to validate (without knowing the underlying analysis), which could result in systems that are easier to certify. In addition, tooling to show if meeting these constraints could be provided.

Furthermore, the following issues were selected as key by participants:

• $\mathrm{■}$

  Is there any hope of treating the path as deterministic (e.g., when looking at main memory access due to cache misses)?

• $\mathrm{■}$

  Literature of real-time analysis and WCET analysis is established – but some busy window assumptions do not compose and have been the source of challenges.

For the second session on the topic, the participants were split into 4 groups, each discussing and reporting their thoughts and ideas on what could be necessary to have functionally safe multi-cores and which other major problems still exist.

• $\mathrm{■}$

  Data sheets are sometimes inconsistent and incorrect which makes it hard to determine the “correct” behaviour and to determine where the uncertainties are. Indeed, the lack of accuracy from official documentation would return as an important issue many times over the course of the seminar.

• $\mathrm{■}$

  Related to this point, how do we verify correctness when we utilize functions, algorithms, and libraries? For instance, even seemingly simple things like the implementation of the EDF scheduler in some RTOSes were shown to be incorrect.

• $\mathrm{■}$

  Functional safety may mean different things on different levels. On a general level, a system may be considered safe if there is no harm to humans. Yet, on the system level, safety may mean, for instance, avoiding race conditions or fulfilling timing requirements. It must be made clear which definition or level is considered.

• $\mathrm{■}$

  Is functional safety the same as being certifiable?

• $\mathrm{■}$

  What is the difference between the properties we care about in safety-critical real-time systems and functionally safe? When can we say we have a sufficient set to ensure safety and how can we guarantee nothing is missing?

• $\mathrm{■}$

  Safety can be argued either by design or by verification. Is it easier to achieve when coming from one direction – and how can these approaches possibly be combined?

• $\mathrm{■}$

  There is a shift from static to dynamic analysis.

• $\mathrm{■}$

  Will hardware at some point reach sufficient performance with full predictability? Or, will this never be the case meaning that we should therefore focus on resilience and safe degradation?

• $\mathrm{■}$

  Is it always necessary to verify that all functional requirements are satisfied? Or, should we determine how much violation of properties can be tolerated or mitigated (e.g., by looking at fault tolerance approaches)?

A topic that participants wanted to cover was that of system certification, the process by which high-integrity and safety-critical systems are certified for use by authorities. Academics are rarely involved in the complicated and time-consuming certification process. Yet, if academic results in the embedded system and real-time domain should be utilized in real-world products, they must usually be certified by the relevant authorities. Therefore, knowledge about the certification process itself, how these results can be transferred, and which assumptions, constraints, and techniques are seen as reasonable (or even at all achievable) by industry is highly relevant for academic research. In these two sessions, we discussed the certification process based, on the one hand, on the industry’s perspective of Victor Jegu from Airbus and, on the other hand, on the perspective of a collaboration between academia and industry, given by Claire Pagetti from ONERA.

The industry panel was organized as a Q & A session where the audience could ask questions which then were answered by Matteo Andreozzi from ARM, Jan Micha Borrmann from Bosch, Victor Jegu from Airbus, Kevin Quinn from General Dynamics, and Zoë Stephenson from Rapita Systems. The panel was moderated by Mitra Nasri from TU Eindhoven. We paraphrase the questions and summarize the provided answers.

• $\mathrm{■}$

  Q1: Do you look at academic papers, e.g., when you have a problem at hand?

  • –

    Industry is more about patents than papers. Unfortunately, already published results can usually not be used in patents.

  • –

    It would be easier if there was a shared wiki with people’s research domains, considered models, etc.

• $\mathrm{■}$

  Q2: What academic assumptions are (un-)reasonable?

  • –

    Academic papers often focus on meeting timing deadlines exactly, but safety-critical systems have to deal with faults. Hence, they are designed to be deterministic – when a deadline is missed, we know what will happen.

  • –

    Shut down is usually not an option when a failure occurs – systems need to be fail-operative.

  • –

    Mixed-criticality for us is about partitioning the electronics.

  • –

    We don’t care specifically about WCET, just that we meet safety requirements and end-to-end response time constraints. WCETs are just the best model we have.

  • –

    Data freshness is important – one should annotate data with timestamps.

  • –

    Focus is more on making correct decisions, not on periodic behavior of polling – it is less helpful to keep polling stale data.

  • –

    For data freshness, the DAG model can be useful. Yet, industry cares about data flow graphs, academics are asking more about control flow graphs.

• $\mathrm{■}$

  Q3: What steps are taken to help increase timing predictability? (Question 19 from a recent survey [1] on industry practice in real-time systems. So, the panelists discussed the answers provided in the survey.)

  • –

    Partitioning caches – should be expanded to more, just general “partitioning shared resources”.

  • –

    If disabling cache, maybe buy a more predictable machine instead.

  • –

    A partitioning argument must be clearly communicable for certification.

  • –

    A bandwidth servers type thing for highest assurance/integrity parts, can simplify RM analysis, one task every 20ms.

  • –

    Regarding cache replacement policies, LRU is well explored in real-time literature and used by some platforms. Yet, ARM (and other) commercial platforms use a proprietary cache replacement mechanism – details on the mechanism cannot be given but some predictability guarantees can be provided.

  • –

    Tools are used for WCET computation. It would be helpful to have an analysis showing the worst-case cache misses as this could reduce the testing needs.

  • –

    One of the biggest needs is observability.

• $\mathrm{■}$

  Q4: Hardware performance counter standardization?

  • –

    PMUs are not designed for dynamic monitoring.

  • –

    Advanced OSes look at splitting up data gathering from monitoring.

• $\mathrm{■}$

  Q5: What do you see as a roadmap for the future, what questions should be answered, and what are future trends?

  • –

    One very important thing when moving real-time support is observability.

  • –

    Can we get to a useful workload modeling abstraction that enables sharing needed info without needing to disclose IP?

  • –

    SHIM: software-hardware interface model.

  • –

    Demos are beneficial as they can show the vision of others.

  • –

    What could we do instead of WCET analysis? Is there another way to meet the safety requirements? Especially when considering the out-of-order execution of “modern” architecture. How does out-of-order execution impact jitter?

  • –

    Partitioning can be a means to manage cost. Yet, it is not 100% reliable – could we get some bounds around that unreliability?

  • –

    Software development takes a long time, at a huge cost and drivers can be as large as the primary code base.

  • –

    Hardware reuse is expected, software needs a huge recertification effort.

After focussing on the industrial perspective in the previous sessions, this session primarily considered potential analysis directions from academia. Rodolfo Pellizzoni from the University of Waterloo provided a general overview from the perspective of static analysis and Sanjoy Baruah from the Washington University in St. Louis moderated the discussion.

A multi-core resource interference analysis is often considering different parts of the system individually. Multiple cores (and other components) thus result in multiple analyses which a performed in a divide-and-conquer approach. For each core, a static analysis and a resource analysis are performed.

The conceptual resource model may be as follows:

• $\mathrm{■}$

  Takes some flow as input (target) and output (initiator) some flows.

• $\mathrm{■}$

  These are the requests (which behave differently for different types).

• $\mathrm{■}$

  Latency depends on the flow under analysis and the interfering ones.

• $\mathrm{■}$

  The process could be (conceptually) iterated to obtain end-to-end latency.

A basic, possibly provable, analysis could be structured as follows:

• $\mathrm{■}$

  Assuming that a model of the resource is available (which is not always the case).

• $\mathrm{■}$

  For each resource and each request, based on the type, an access pattern that causes the worst-case latency is determined.

• $\mathrm{■}$

  Sum the latency over all requests.

• $\mathrm{■}$

  For each program under analysis, sum over resources and add the total latency.

This approach could be safe (with caveats) but would be extremely pessimistic. At least the following sources of pessimism must be considered.

1. 1.

   Request Distribution

   • $\mathrm{■}$

     There is often no information on request distribution. Yet, these distributions may potentially be obtained by program analysis or by observation. If pathological cases are triggered they may result in a 100x increased latency. Many hardware structures that are designed to not saturate under a “normal” operation flow stall once such a case happens.

   • $\mathrm{■}$

     A key issue is to capture the burstiness over time. Potential modeling approaches:

     1. (a)

        Determining the number of requests over a given time window – for both the flow under analysis and for interfering ones. Problems with this approach include that it is imprecise, it is unclear how to cover bursts correctly, that large time windows must be considered, and how windows are synchronized.

     2. (b)

        Request curves as in, for instance, network calculus. These curves separate burst and rate and can be deterministic or stochastic. However, determining arrival curves for network calculus is non-trivial and it must be guaranteed that the backlog is smaller than the buffer size to avoid “backpressure”.

2. 2.

   Latency Sensitivity

   • $\mathrm{■}$

     General idea: sum latency of all requests to the WCET.

   • $\mathrm{■}$

     Yet, not all requests necessarily add latency to the core (e.g., reads can be prefetched).

   • $\mathrm{■}$

     Out of Order cores can reorder operations and tolerate some load latency. This can potentially be accounted for by computing a tolerance term per request if alignment issues can be solved.

3. 3.

   Missing Pipeline Effects

   • $\mathrm{■}$

     One interfering request may add delay on multiple resources.

Additional problems often arise since a precise resource model is either not available or too complex to be analyzed in practice. One potential solution, often used in academia, is to use a simpler, approximated model where the input-output characterization ensures that the output curve is always “safe”. Yet, this property can likely only hold of system configured through partitioning (best in hardware).

Unfortunately, static analysis may not be the solution for the multi-core era, as finding a correct abstract interpretation of a modern superscalar out-of-order core may be (nearly) impossible. Instead, one may try other directions by examining the following questions.

• $\mathrm{■}$

  Is some kind of hybrid analysis possible?

• $\mathrm{■}$

  Could added observability help strengthen the case?

• $\mathrm{■}$

  Can we reach hard guarantees in soft systems?

• $\mathrm{■}$

  What dependencies do we need to look at?

• $\mathrm{■}$

  If we do not need worst-case, what do we need? Can we rely on statistical arguments?

• $\mathrm{■}$

  Could we look at a set of possible WCET values?

As noted earlier in the report, undergoing the lengthy certification process is not something that academics generally take part in. Participants invited Zoö Stevenson from Rapita Systems to give an overview of her experience in supporting certification through DO-178C. It is the main certification document that describes the approval process for commercial aerospace systems. It is used by a range of countries including the US, Canada, and the EU and conformance to DO-178C is a key requirement for many tool vendors. Rapita Systemes provides both software tooling and analysis of user software, with the aim of certifying complex systems to this level.

A key point to highlight is that there is often a disconnection between software-level concerns and certification-level concerns. A feature of key importance to the software developer, may not necessarily be linked to system component of correspondingly high integrity. Software level does not imply failure level, so it is not possible to directly use software reliability as part of the certification argument.

A common misconception about certification documents, such as DO-178C, is that they give a list of system requirements which must be fulfilled and a checklist of tests to be performed. Rather, requirements come from system design, and so certification is concerned with the overall system and the evidence that is necessary to discharge safety requirements. For example, if the developer is using Ada, which contains a range of exception-handling systems, DO-178C will still require such systems are tested, and their efficacy demonstrated, if such systems are linked to the discharging of a safety requirement.

The applicant is responsible for oversight of all of its suppliers. This has wide-ranging implications for the way the software is developed integrated and analysed. The system must be analysed as a whole, with an analysis performed on the integrated software stack. All tool vendors and software vendors in this domain work to support this process.

The resulting certification argument is a combination of reviews, analyses, and tests. Significant training for employees is needed to support all stages of this process. A Software Quality Assurance process (SQA) will often form part of this evidence, through compliance to a relevant standard such as AS9100.

The final observation was on the semantics of certification documents. The previous version of 178C, 178B, was often used by vendors as prescriptive. If the document didn’t mention something then it was presumed that you could not use it. This had wide-ranging implications for the range of development techniques, such as object-orientation, and of hardware platforms, such as FPGAs. More recent certification documents do not take this stance, but progress in these areas remains slow.

In the following Q&A, participants noted that it would be useful as a community to have an entire certification packet as an example. This is difficult because as has been noted, certification is a very lengthy and incredibly expensive process and necessarily reveals large amount of commercially sensitive information. Accordingly, it would have to be undertaken as part of a publicly funded project and while there are some burgeoning projects in this area, nothing has as of yet been completed.

Timothy Bourke from INRIA & ENS in Paris discussed programming languages and (machine-checked) models with a focus on the additional challenges that arise when examining the timing behaviour in a multi-core environment. The process has a wide set of potential requirements and strategies. Hence, there is a tradeoff between opportunities and risks, for instance, for the exploitation of hardware, concurrency and related issues (like race conditions), or when considering inter-core interference sources.

The verification process results in a large argumentation tree, where the correct branch needs to be selected based on the component and the confidence. The interference analysis model can be built using PML. An appropriate documentation must be provided for the purpose of timing analysis. If one wants to do the same for schedulability, it must be determined what guarantees each test provides. In addition, to apply such an approach in multi-core systems, it might be necessary to utilize hardware designed for predictability or hardware that provides increased observability.

Mathieu Jan from CEA LIST talked about opportunities for combined hardware/software modeling for the formal verification of timing behaviour, using RISC-V as an example. He highlighted that it is important to identify timing anomalies – these do not necessarily need to be eliminated but they must be accounted for. This can be achieved by considering multiple traces. The 6-stage RISC-V rocket pipeline must be modeled (either manually or with an automatic tool). The TLA+ pipeline specifications are extended with instructions and control path.

This session was lead by Jian-Jia Chen TU Dortmund University and aimed to answer the question, “how much predictable computing do we actually need?” A key theme that was emerging from the discussions was that it is possible for academics to solve problems that do not actually need to be solved. Fundamentally this comes from the fact that academics want to solve problems, and engineers want to avoid problems.

Consider the commonly used terminology to determine the real-time constraints of a given system component:

• $\mathrm{■}$

  Hard – the component should never violate timing.

• $\mathrm{■}$

  Firm – the component may violate timing, but this would never be seen at the application level, i.e. violations are handled.

• $\mathrm{■}$

  Soft – this component is allowed timing violations up to some stated level of assurance.

Academics tend to focus on 100% hard real-time systems, but real-world workloads are a mixture of different levels of assurance. This varies heavily from domain to domain; the needs of the automotive industry are very different from that of avionics or manufacturing, for example.

The application domains that should be considered most useful for focusing academic research were then discussed. There is currently a lot of interest in the field of autonomous driving and the interesting problems that it represents, but if pursued too much may result in too narrow a focus.

Instead of putting applications into ‘buckets’ and considering them in isolation, we should instead attempt to develop a range of system models that can be later matched to application classes. The reason for this is that application classes will change over time, and the speed of the industry means that this can sometimes be quite rapid. Cloud computing, big data, and autonomous driving are all examples of application classes that have appeared rapidly and driven a large amount of academic interest.

An example given was that of the Mixed Criticality System (MCS) model. Instead of focusing on a specific domain or application, MCS aims to be a way of building systems that can switch between different levels of assurance. It is a well-studied theory, and its generality means that it is starting to see use in a wide range of areas.

Our system models must recognise that industry is less focused on characterising workloads and more on the system-level requirements that they must fulfill. Timing correctness is an important tool for the verification of these requirements, but it is merely a derived requirement.

Chris Gill from Washington University in Saint Louis discussed the properties needed from hardware and middleware based on example projects he participated in. He emphasized that due to the large scope of embedded and cyber-physical systems applications have different needs and constraints; thus, application-specific semantics matter more than ever. For instance, sensor types, energy requirements, memory and cache sizes, the number of cores as well as the core speed, and the overhead to interconnect these cores may differ largely. As a result, general abstractions and generalizations are hard to find and it seems problematic to find a general approach for decomposing systems. Yet, it would be nice to have a list of constraints and construct adaptable scheduling to meet those.

Micha Borrmann from Bosch GmbH then discussed how these issues are addressed in real-world hardware development by enumerating some of the challenges in highly-available automotive computing. Automotive systems are moving from using a large network of low-power devices towards greater centralisation of computing resources in a few high-powered multicore platforms. This results in a large number of safety and security requirements that must be addressed. This necessitates a complete rethink in the way that automotive systems can be built, and is an active area of development.

The seminar was concluded with an roundtable session in which the open research challenges as well as questions and thoughts were collected. The goal of this was to collect the thoughts of the participants as they had evolved over the course of the seminar, and to ask the questions would should drive the direction of research for the next decade. We collected top level observations, and the questions that stem from each of these.

• $\mathrm{■}$

  Maybe hard real-time is not the most accurate model.

  • –

    Time is a means to some end – not the end goal.

  • –

    Timing is also still an unsolved problem, and getting more complex

  • –

    In real-time, when we specify tasks, we focus on time parameters. Should we also look at logical correctness? Are the correct values produced? Usually, we assume functional/logical correctness – this assumption may need to be challenged.

  • –

    Is reliability a fundamental thing we must provide?

  • –

    Trust and probability may be interesting metrics to consider.

  • –

    Distinguish functional correctness and fault tolerance.

  • –

    Non-functional properties are important: composability, extensibility, robustness, parametric simplicity.

• $\mathrm{■}$

  Applications are very complex, but platforms are amazingly complex.

  • –

    We consider algorithms (scheduling algorithms, protocols), we need to make sure these are actually correctly implemented – separate concerns: analysis is correct, implementation is correct. For instance, PROSA vs. given implementation – does the implantation match the model?

  • –

    When it comes to partitioning: how do we ensure two components do not interfere? This is a huge engineering effort, with hours of time per line of code.

  • –

    Why should one use more complex architecture, requiring hugely complex analysis? One could consider building a simpler architecture.

  • –

    Is the right way to look at uniprocessor techniques and determine how we can extend them to multicore? OR, should we do an entire redesign of analyses?

  • –

    Safely-critical applications cannot simply just apply a patch, they need recertification.

• $\mathrm{■}$

  There is a value of consensus in the research community.

  • –

    Dependability and fault-tolerance research communities study these and are working with some industries. Do we need to integrate? Can we rely on other work?

  • –

    Do we analyze too complex systems? Engineers often repeatedly simplify problems.

  • –

    It would be nice to know where we are losing. For example, why is a system using $X$ unable to pass certification?

  • –

    Instead of asking if a model is good, try to use it.

• $\mathrm{■}$

  What is the set of requirements?

  • –

    Specifications and documentation will often have flaws.

  • –

    Does the OS meet specs – industry finds this is not always the case. Is a verified OS a solution?

  • –

    There are assumptions even in abstractions, simulations for physical hardware – we cannot fully capture physics in the model.

  • –

    Models need to be as simple as possible for real use vs. expressive, complex models.

Many discussions centred around the system models that we create. It was observed that there is a clear tradeoff between accuracy and model simplicity. Formal models for safety certification ideally should satisfy or include:

• $\mathrm{■}$

  criticality

• $\mathrm{■}$

  environment assumptions

• $\mathrm{■}$

  developer-friendly tooling

• $\mathrm{■}$

  predictions about (worst-case) system behavior

• $\mathrm{■}$

  features acceptable to the certification authority

However, the process of modeling can have violations throughout this process:

• $\mathrm{■}$

  model compliance

• $\mathrm{■}$

  assumption validity

• $\mathrm{■}$

  analysis soundness

• $\mathrm{■}$

  implementation correctness

• $\mathrm{■}$

  analysis accuracy

• $\mathrm{■}$

  explainability

There clearly is therefore an identified need to keep people talking. This seminar showed the unique value in something which is critically lacking in our discipline, the ability for practitioners and academic experts to get together in the same room and to pass ideas to each other. Models need refining which can support certification, be reflected by hardware, be used by developers, and be analysed for correctness by tooling. Only with a cross-cutting integrated approach from all levels of the development stack can this succeed.

• $\mathrm{■}$

  Sebastian Altmeyer – Universität Augsburg, DE

• $\mathrm{■}$

  Tanya Amert – Carleton College – Northfield, US

• $\mathrm{■}$

  Matteo Andreozzi – Arm – Cambridge, GB

• $\mathrm{■}$

  Sanjoy Baruah – Washington University – St. Louis, US

• $\mathrm{■}$

  Jan Micha Borrmann – Robert Bosch GmbH – Stuttgart, DE

• $\mathrm{■}$

  Timothy Bourke – INRIA & ENS Paris, FR

• $\mathrm{■}$

  Björn B. Brandenburg – MPI-SWS – Kaiserslautern, DE

• $\mathrm{■}$

  Jian-Jia Chen – TU Dortmund, DE

• $\mathrm{■}$

  Christian Ferdinand – AbsInt – Saarbrücken, DE

• $\mathrm{■}$

  Julien Forget – University of Lille, FR

• $\mathrm{■}$

  Anna Friebe – Mälardalen University – Västeras, SE

• $\mathrm{■}$

  Chris Gill – Washington University – St. Louis, US

• $\mathrm{■}$

  Ian Gray – University of York, GB

• $\mathrm{■}$

  Arpan Gujarati – University of British Columbia – Vancouver, CA

• $\mathrm{■}$

  Robin Hapka – TU Braunschweig, DE

• $\mathrm{■}$

  Mathieu Jan – CEA LIST – Gif-sur-Yvette, FR

• $\mathrm{■}$

  Victor Jegu – Airbus S.A.S. – Toulouse, FR

• $\mathrm{■}$

  Eric Jenn – IRT Antoine de Saint Exupéry – Toulouse, FR

• $\mathrm{■}$

  Mitra Nasri – TU Eindhoven, NL

• $\mathrm{■}$

  Geoffrey Nelissen – TU Eindhoven, NL

• $\mathrm{■}$

  Catherine Nemitz – Davidson College, US

• $\mathrm{■}$

  Claire Pagetti – ONERA – Toulouse, FR

• $\mathrm{■}$

  Sri Parameswaran – University of Sydney, AU

• $\mathrm{■}$

  Rodolfo Pellizzoni – University of Waterloo, CA

• $\mathrm{■}$

  Kevin Quinn – General Dynamics – St Leonards on Sea, GB

• $\mathrm{■}$

  Jan Reineke – Universität des Saarlandes – Saarbrücken, DE

• $\mathrm{■}$

  Benjamin Rouxel – University of Modena, IT

• $\mathrm{■}$

  Selma Saidi – TU Dortmund, DE

• $\mathrm{■}$

  Matheus Schuh – Kalray – Montbonnot-Saint-Martin, FR

• $\mathrm{■}$

  Zoë Stephenson – Rapita Systems Ltd. – York, GB

• $\mathrm{■}$

  Jürgen Teich – Universität Erlangen- Nürnberg, DE

• $\mathrm{■}$

  Georg von der Brüggen – TU Dortmund, DE

• $\mathrm{■}$

  Bryan Ward – Vanderbilt University – Nashville, US

• $\mathrm{■}$

  Reinhard Wilhelm – Universität des Saarlandes – Saarbrücken, DE

• $\mathrm{■}$

  Houssam-Eddine Zahaf – University of Nantes, FR