Session 4B: Model Driven Approaches

Keywords: Model Driven Architecture, Templates, JSP, Generative Programming

The MDA (Model Driven Architecture) approach by the OMG has been evolved as a defacto-standard for modern modelling tools. MDA uses the UML, which is based on top of programming language concepts. Therefore it is fairly limited when using it in the automotive domain, since the UML offers only limited ways for adapting it to special purposes. A possible solution is to replace the UML with a domain specific modelling language (DSML). This implies also dismissing the existence of UML profiles, since the DSML includes them already. In this article we show an approach to take advantages of the MDA combined with the power of domain specific models. We built a code generator using the Java Server Pages (JSP) technology and are able to transform any domain model into code or other artefacts.

Introduction

The foundation of the MDA approach is the UML. In conjunction with UML profiles they form a platform independent model, which are dedicated to a certain domain. By defining architectural styles and transformation rules, the PIM can be transformed to a platform specific model (PSM). In the last step, the PSM is transformed into source code or other artifacts [OMG].

The reader may argue, that MDA knows already the concept of domain specific models, but the difference between MDA and a DSML may be huge, since domain specific part in MDA is often realized by defining additional stereotypes resp. tagged values, but the UML notation is kept. Additionally most case tools do not distinguish between PIM and PSM due to weak UML extension mechanisms. Instead, the modeler defines the needed stereotypes directly and passes the model to a code generator (sometimes called "MDA light" [MDA2003]).

The knowledge about transforming a model into code often lies in code generators resp. in their templates.

So there is a need for a modeling language, which supplies terms, elements and rules used in a domain, a domain specific modeling language. By replacing UML with a DSML, we can combine the strengths of MDA and DSM's. Unfortunately it is not surprisingly, that most code generators rely on UML. So we developed a template-based code generator, which is dedicated to a domain specific modeling language [Pr2003].

Transformation of a DSM into code

To realize the described approach, we first had to define a DSM. In our project we used Architecture Definition Language (ADL) by the ITEA1 /EAST2 -EEA3 project.

EAST/EEA is a research project sponsored by the european community. Participants are car manufactures, suppliers and research institutes. The goal is the development of an open software architecture, which allows a flexible distribution of functions in a car.

One important deliverable is the ADL to describe the problem space of car ECU's. It is founded on UML 2 concepts but has certain extensions, e. g. variability and hardware issues.

The ADL was created with GME 2000, a free modeling tool by the Institute for Software Integrated Systems (ISIS) at the Vanderbuilt University (USA). It allows the definition of DSML's as well as the creation of DSM's on top of a DSML. GME 2000 provides a set of basic elements (atom, connections, constraints, etc.) to form a DSML. After the definition of the DSML, GME 2000 can be used as CASE tool to develop a model according to the previously defined DSML.

According to the MDA paradigm, we need a tool, which is able to transform the PIM/PSM into source code. Most CASE tools provide a code generator, which uses templates to realize the transformation step. Templates can be described as "intelligent text files". Besides static text they contain embedded code to control the generation process. Typically a common programming or scripting language (e. g. Python or Tcl/Tk) is used for this purpose. This technique allows a very fine-grain adoption of the generation output. In our project we chose Java resp. JSP as template language.

Collecting Requirements

Obviously, the main purpose of a code generator is to generate code. But there are some issues that makes live easier. First, templates should be modular in order to grant maintainable and reusable templates. Second, existing code should be easy to integrate into templates. Once integrated, this code must be protected in subsequent generation runs and must not be lost.

Third, syntactical errors in the template should be easily trackable. During the generation process the template is transformed into a java class. Of course, the compiler tells us the error location in the source code, but it is very difficult to track it back to the template, since the mapping between template and the corresponding java code is not straightforward. Finally, changing the target technology ("projection") should be done without changing a template. With projection we mean the transformation rules to a certain programming language, architecture or even hardware platform. From a more general point of view, the generator should not be usable for all kinds of domain specific models. So it must not contain constructs, which are dedicated to a particular domain.

Designing the Code Generator

In this section we explain the foundations of the code generator. Since we decided to use JSP, the architecture of the code generator relies heavily on this technology. So we focus on it in order to demonstrate the working method of the generator. Figure 1 shows the transformation process of a JSP template into generated code. Strictly speaking, there are two generation steps. First, the JSP template is transformed into instrumented java source code. Second, the source code is compiled into a java class. Finally, the class is executed which produces the defined output (second generation step).

Figure 1 -Transformation Process from Template into Code

With respect to the requirements stated above, we will talk about possible consequences and solutions.

Why not using an existing JSP engine?

One of the first questions which came up was the make-or-buy decision. There are a lot of free available JSP engines, which supports the complete JSP standard. But they are unsurprisingly designed for the original purpose of JSP, namely generation of dynamic web pages. So we have to carry a lot of code without using it and cutting the unused pieces is more work than implementing a lean JSP engine. Additionally we have to adapt the engine to our needs. With respect to the complexity of these engines this leads to a very high effort.

Code Merging

The field of code merging is a complex one. An obvious solution may be a merging mechanism like CVS. But the situation here is a little bit different. Every line in a source file has the same origin and "equal rights". So the algorithm can decide, which parts should be inserted or dropped. The problem with generated code is a question of priorization. In other words, who decides, which part should be preserved: User defined code or generated code? The decision depends heavily on the generation context, but there is no (convenient) way to store the context information in the generated code.

Therefore we chose another way to protect user-defined code, which is also used by others code generators: Protected Areas. Code inside these areas will be preserved in subsequent generation runs. The developer can define them by inserting special tag pairs in the template, as shown in Figure 2.

Maintainability and Reusability

The key issue for maintainability and reusability is modularity. JSP already offers the include-command, which allows the inclusion or further JSP files resp. templates. Another concept of JSP that supports this quality are tag libs. Tag libs contain userdefined tags that capsule recurring code fragments (e. g. iterations, switch-case). The code generator supports both approaches.

Master and Code Templates

We distinguish between two different kinds of templates. On the one hand we have templates for code generation as depicted in Figure 3. On the other hand we have a master template, which maps model elements to appropriate templates (Figure 4) and is responsible for compound operations, e. g. pre-and postprocessing of the generation process. Preprocessing is useful to prepare the generation process. During generation, templates are allowed to store informations in user-defined lists. For example, every template for a certain artefact may store its file name in a list. After the code generation has finished, the master template may evaluate these lists to generate a makefile or a deployment descriptor. The concept of master templates hides the generation details from the generator and allows a better maintenance of different projections.

An Example Model

To demonstrate the abilities of the code generator, we chose a simple model of an Adaptive Cruise Control System (ACC). ACC enables a car to drive automatically in a stop-and-go situation. To that it warns the driver if the distance to another car becomes too short or brakes even the car, if necessary. One of the work products of the ITEA project is a sample ACC model described with the ITEA ADL. The ADL founds on UML 2 concepts, but offers some extensions, e.

Conclusions and Future Work

In this article we showed a lightweight MDA approach. By replacing UML with a domain specific modeling language, we get a more flexible way to describe and solve domain specific problems. On the other hand we have to consider the initial effort to create a domain specific model. So we started with an existing domain model and used the code generator to transform the model into C code. Moving to another programming language should be very easy with this approach.

Future work may result in further model extensions. For example, a model element may contain quality attributes to select a template, which contains appropriate mechanisms (e. g. global variables instead of local variables in order to save resources).

Another example may consider further model informations, e. g. sequence diagrams to setup a scheduler or test cases, which check the timing constraints in real-time applications.

In short, every step towards increasing quality and quantity of code will result in a more comprehensive model. Another interesting field in context of domain specific models may be aspect-orientation or establishing "model bridges" to other domains [Mell2003].

Figure 2 -

 2 Figure 2 -Protected Areas

Figure 3 -

 3 Figure 3 -Sample Code Template

  g. to model the hardware architecture of an ECU.

Figure 4 -

 4 Figure 4 -Sample Master Template

-22 -23 January 2004

ITEA: Information Technology for European Advancement

EAST: Embedded Architecture and Software Technologies

EEA: Embedded Electronic Architecture

Author

Dipl.-Wirt.Ing. Oliver Wieland Robert Bosch GmbH

Brief Biography

Mr. Wieland has been working for Robert Bosch since 2001 and is responsible for researching and introducing software engineering methods to the product divisions. Previously he worked as a consultant in the field of software architectures and model driven architecture.


Florent Feve
email: florent.feve@valeo.com

Gérard Foin

Gilles Le Calvez

Session 4B: Model Driven Approaches Software Model-based Development for automotive

Keywords:

Using modeling tools to simulate the behavior of a system before developing the corresponding product(s), is now becoming a common approach for the automotive industry, but many challenges remain. In order to obtain a seamless and efficient process for a whole software development we must pay attention to the choice of the modeling tool(s). Modeling tool(s) must be easily connected with other commercial and in-house tools used for the development. The usual software development methodology must be adapted to fully take advantage of those tools. Automatic code generation as well as modeling tools database access capability gives the opportunity to improve the global code test strategy. Whatever the performances of the tools are, the process applied remains a key point for the development.

This paper explains the innovative approach that has been developed to meet the challenges described above. The corresponding VALEO model-based development process is based on Statemate, Rhapsody in Micro C, static and dynamic test tools and in-house tools.

INTRODUCTION

It has long been recognized that ambiguous and inconsistent requirements are the primary cause of system design errors.

The global process of VALEO model-based development provides solutions to this critical issue. It involves the initial functional model, followed by the software design model, automatic code generation and the automatic software and product validation bench. In addition, the global process offers, as a spin-off, traceability between all the different development steps. The automatic link will be detailed between requirements specification and validation, as well as the automatic link between requirements specification and the code implemented in the product. Finally a general description of the current code test strategy will be given and the planned improvements will be presented.

MODEL-BASED SOFWARE DEVELOPMENT PROCESS

In recent years several modeling tools have come out. The use of these tools produces a real improvement in software development. It ensures that the product being developed relates to the goal and purpose of the system. Nevertheless, most of these tools are time-consuming, and they do not yet bring about seamless software development. Due to this lack of overall efficiency, the user cannot take full advantage of the initial time investment they require. Indeed, in many cases there is a gap between the generated model and the implementation on the one hand, and, on the other hand, between the model and the validation test of the product. After explaining these two gaps, this paper presents the solutions developed.

BRIDGING THE GAP IN THE IMPLEMENTATION PROCESS

The first potential gap lies between the functional reference model and further application code implementation. Using a tool to only model the functional requirements in order to have a functional reference is interesting, but one still needs to make a manual design of software and to develop the code. To avoid having a gap between the model and the implementation, automatic code generation capability is now used.

There are a lot of modeling and code generation tools on the market. Although code generation technology has significantly matured during recent years, the results are often inappropriate for embedded software. The reason is that several attempts have been made to generate embedded code from a system or functional model without making any software design. The result is that the implementation isn't suited for Design constraints such as timing constraint, tasks synchronization, timing bottlenecks, RAM and ROM constraints etc.

On the other hand, if one uses an implementation-or design-oriented modeling tool, the generated code may meet embedded software constraints (if the code generator is efficient enough), but the model will take much longer to develop and be much harder to maintain. Taking into account and evaluating the impact of change requests will be long and tedious; the risks are then similar to those taken when one goes directly from the customer requirements to the software implementation using a manual process without writing a software requirement document.

BRIDGING THE GAP WITH VALIDATION TESTS

The validation step of a product is a very important phase of development as to duration for two reasons. The first reason is that a great attention is required to elaborate the right tests. Indeed, due to time to market constraints, the number of tests that can possibly be executed on the product is limited. Therefore only relevant ones should appear in the Validation Plan and, as far as possible, every relevant scenario should be thought of and considered. The second reason is that tests on the product will be applied many times, from the first mock-up to the final product. Each time a new version is generated in order to take into account customer change requests, the entire validation plan will be applied for non-regression testing.

Once the model is validated it becomes the functional reference. This validation is done through simulation and record capability of the tool. When the product is to be developed, equivalent tests will be made to validate the final product. One challenge here is to compare the results of the functional simulation model with the results of the corresponding validation test on the product, since the physical characteristics of the inputs and outputs are not taken into account in the functional model. The second challenge is to reduce the duration of this validation phase by re-using the model test.

MODEL-BASED PROCESS

The VALEO model-based software development process has been established in order to bridge these two gaps. Figure 1 shows that, on the classical V curve, modeling and simulation tools have been added as well as an automatic code generation tool. To take full advantage of the use of these tools, internal modeling rules as well as in-house tools have been developed in order to make the process seamless and increase the efficiency of the different test steps.

Figure 1. Model-Based Software Development Process

The Statemate tool is used for functional system and software modeling, and Rhapsody in Micro C tool for global software design and automatic code generation. The databases of these two tools are compatible. We clearly begin with a functional model, without taking into account the implementation constraints, to obtain a functional reference that can be validated by the customer through a PC platform executable. The model is then transformed into a global design making a new functional breakdown if necessary and adding design attributes.

The tool database access capability is used to optimize the test steps by formatting files for direct input of the code test tools.

The link between the functional model and validation is provided by an in-house executable that has been added as a plug-in in the Statemate environment. It enables the test scenarios to be captured via graphic panels and automatically generates the corresponding graphic test in a statechart format out of which test script for automatic validation bench is extracted as well as the validation plan documentation.

Validation Scripts

The Validation scripts used as direct input for automatic validation bench are the exact translation of the tests scenarios applied on the model.

Validation Plan Documentation

A Validation Plan Document is automatically generated including textual and/or graphical representation of each test. This validation plan is ready to deliver to the customer.

Requirement validation with the customer

Communication with the customer concerning the validation of the requirements understanding will be done by using :

A. Before developing the functional model The challenge of the process during the downward side of the V curve is to maintain consistency, from the requirement to the implementation.

Two models are made: the first one is for the system and software functional requirements specification to validate the customer requirements, and the second for the software global design to automatically generate the code ; consequently the consistency between these two models must be checked from a block box point of view. This can be easily done because Statemate and Rhapsody in Micro C have compatible databases, and their record format files are identical.

Figure 6. Consistency check between Functional and Design model

As illustrated in Figure 6, a black box test is performed on the functional model using the graphical tests and recording the inputs and outputs in two different files. These tests are also performed on the functional part of the design model from which the code is generated. A PC platform executable has been generated. Input record files can be directly re-run on the PC platform executable and the results compared to ensure that the design constraints meet the requirements.

Once the consistency has been checked from a block box functional point of view, the code should be generated for a specific micro controller and linked with the low layers. Application Programming Interfaces have been defined in order to link the application layer generated automatically from the model to the low layers written manually, including local device Management, Communication management, driver components management and basic software components (Figure 7).

As to integration with OS, Rhapsody in Micro C enables the user to customize the code generation so that it will fit the OS characteristics exactly. Therefore it can target a scheduler-based implementation, as well as any OSEK or in-house OS without having to evolve the model.

Figure 7 describes the global approach for Micro controller target implementation from a model.

To have an efficient process it has been necessary to define strict modeling rules concerning model architecture and naming rules. These rules have been defined to facilitate the translation of the functional model into a design model without setting any constraint on the functional model. This one should remain readable and maintainable.

The initial step of design model development is the importation of the functional model. This model is then transformed into a design one. Task allocating, precise data typing and design attributes are defined. Then a PC platform executable (of the application part of the model) is generated in order to check the consistency between the two models.

Once the functionality is ensured, the manual C code (low layers) and any external application C code are integrated. The target configuration is also defined in a code generation profile to generate an executable for a specific target.

The design modeling tool is flexible enough to allow external C code to be linked to any part of the model. This is done either by linking a specific C code function to a specific activity (function) of the model or by linking a full C file through a code generation menu when generating the final executable.

A first mock-up is then generated including debug communication in order to test the software on the target connected to the model for graphical debug.

This first debugging and trouble-shooting of the software running on the final target are easily done through the graphical animation of the model on a PC linked to the target.

Optimization at the model level can then be made to reduce the code size. Each time an evolution is made in the design model a new PC platform executable is generated to check the consistency between the functional and design models before generating the target version. Since the automatic code generator used is not certified, the same level of testing as for manual code is required. To apply the same test tools on both manual and automatic codes, these must respect the internal rules in terms of structure, presentation and naming rules. This is possible due to the fact that the automatic code generation is fully customizable.

Implementation test

As illustrated in Figure 9, prior to Unit Test, customized commercial tools are applied on the whole code (manual and automatic) to make static code analysis. VALEO internal naming rules compliance reports are generated and therefore, MISRA rules which are included in VALEO rules are checked. Using the dynamic code analysis tool in combination with modeling and code generation tools significantly improves the process. Indeed one characteristic of dynamic code analysis is that the duration of the tool analysis can be rather long (from few hours to several weeks depending on the project) and that once the tool has finished the analysis, a big amount of work remains for the developers to analyze the report generated by the tool. This duration can be reduced by limiting the number of combinations. Defining a range for each input and output data will limit the overall calculation and the number of warnings, thus limiting the duration of the tool results analysis. This range information is included, during specification and design steps, in the model data dictionary using specific customized attributes. As shown in Figure 10 the code generator is customized so that, in the generated C files, the data range appears as a comment which is identified with a specific token. An in-house tool automatically extracts the range information and configures the C files so that the dynamic code test tool optimizes the analysis. As mentioned above, Validation scripts are used as a direct input for automatic validation bench. They are the exact transcription of the test scenario applied on the model. This is a great improvement compared with the process in which model testing is first recorded and then equivalent scenarios are handwritten in a specific script format to rerun the same test on the final product to compare the results.

Extracted from the test state charts, the test scripts contain the functional sequence as well as all necessary information for the validation sheet, including the test number, the description of the test, requirement(s) under validation and validation bench configuration information if necessary. The scripts are generated in RTF format with a generic format for stimulating inputs and verifying outputs.

Macros are used to translate the functional inputs and outputs into physical ones, taking into account the physical characteristics of each ECU and allowing very easy adaptation in case of hardware changes. Whatever the physical support of the inputs/outputs may be (logical, analogical, PWM, network), the validation plan and validation script will be up-to-date with this methodology. Only macro implementation takes into account the physical support.

Once the scripts have been executed on the automatic Validation Bench, the results are compared with the simulation results which are the reference for the validation tests (Figure 12).

Figure 12 Validation Process

The global approach for model and product validation is described in Figure 13. Another great item of interest of this process, is the traceability capability.

An Attributes-specific field of the modeling tool allows the user to enter pre-formatted information linked to any element of the model. This Attributes field is used to establish the traceability.

At the beginning of the development, textual requirements are analyzed and each requirement is identified. A label is assigned to each requirement.

• The reference to the requirement(s) is established during the definition of test scenarios via graphic panels.

Automatic generation of the graphical test fills the Attributes traceability field with the requirement(s) label(s). • When developing the functional model each element implements one or several requirement(s) . Again traceability is ensured by filling the Attributes traceability field with the corresponding label(s). • The design inherits this traceability automatically since the functional model is the starting point for the design model . The Attributes traceability field is filled for each added design element. • Finally the code generation profile has been customized so that traceability information (label(s) of the Attributes traceability field) appears as comments for every C code function.

An in-house development enables users to extract the total traceability matrix in an Excel format through a fully integrated tool suite (Figure 14). Obviously, the availability of functional system models provides a safe ground for all the following software development and validation. The entire Valeo process takes full advantage of this ground in a seamless development, with tools which are all connected to this initial step. The gaps often observed in validated development methods, as mentioned above, have been bridged.

Traceability management

Figure 2 .

 2 Figure 2. Formalization of Requirements (shaded area)

•

  Figure 4. Prototyping During model development and once finished, graphic tests through simulation test bench are applied to check the conformity. Tests can be recorded during simulation in Sequence Diagram format to be analyzed easily. In addition, a virtual prototype (PC platform executable) is delivered. Rapid prototyping on an oversized target can also be delivered in order to have a physical ECU representative of the behavior.

Figure 8 .

 8 Figure 8. Testing the implementation (shaded area)

Figure 9 .

 9 Figure 9. Static code analysis

Figure

  Figure 10. Run time error check

Figure 13 .

 13 Figure 13. Model-Based Process : global approach to validation

Figure 14 .

 14 Figure 14. Traceability Matrix When a change request is made, the impact on the functional model, software design, C code functions, and validation test is immediately identified. CONCLUSION A seamless model based development process has been demonstrated and its efficiency validated. It has actually been shown to improve communication between different members of the development team and customers, and to reduce time to market. This has been achieved while increasing the overall development quality.

-22 -23 January 2004

-22 -23 January 2004Figure 7. Model-Based Process : global approach for implementation

ACKNOWLEDGMENTS

The authors thank P. Germanicus, G.M. Martin and S. Zamia for advice and support.

This innovative process has been applied partly to the development of an industrial project currently under production. It has already brought great quality improvement and significantly reduced development time.

Nevertheless the process can be improved in particular for C code testing. Work is already planned to take advantage of the code generation combined with data range information to optimize the code Unit tests. The aim is to automate the unit tests to have a coverage analysis as well as functional, structural and robustness run time error detection.

The automatic link between specification and validation is a key in the process ; it dramatically reduces the validation phase, ensures the consistency of the process and is very flexible. It can be very easily adapted to any specific automatic test bench modifying a small and well-identified part of the in-house tool.

Regarding validation, new tools based on mathematical analysis of models such as BDD or Symbolic representation, where the goal is to generate automatically relevant tests from a model, are also being evaluated.

The current process is ready to integrate these tools as soon as they have been fully developed.

CONTACT


Lei Xi
email: lei.xi@sorbonne-nouvelle.fr

Claire Pillot-Loiseau

ACOUSTIC AND PERCEPTIVE STUDIES OF CHINESE LEARNERS PRODUCING THREE BASIC FRENCH INTONATION PATTERNS

Keywords: L2 intonation acquisition, French, Mandarin Chinese, perception, acoustic

The productions of French final neutral declarative, polar question with "est-ce que" and major continuation by seven Chinese learners of French (CL) and six French native speakers (NS) were perceptually (perception tests for two of these intonation patterns) and acoustically analysed (difference between F0 ending and F0 beginning a stress group (F0-diff); F0 range in stress group). The "est-ce que" questions produced by the NS were perceived as an affirmation, those of the CL as a question. The major continuations of the NS were perceived as a question, those of the CL as an affirmation and a question. For declarative, the CL did a falling contour with a F0 range too small or too large compared to the NS; for rising contour, the same F0-diff and F0 range characterized the polar and the total questions of the CL. Concerning major continuation, unlike NS, CL sometimes perform rising and falling contours.

INTRODUCTION AND GOAL

It has been widely shown that prosodic factors are as important as segmental factors in speech 2,5,8,9,12,17. Globally speaking, prosody is an important element for understanding meaning in speech perception and for making oneself understood in speech production 2,5,17. Despite the fact that prosody is an important tool for negotiating meaning, managing interaction, and achieving discourse coherence, L2 learners have generally not been taught how to use intonation to signal discourse strategies 5. Especially, research examining problems and difficulties which Chinese learners (CL) face in learning French, suprasegmental elements are very rare. In the literature, only a few studies have addressed this question 4,12,13,15. Therefore, the current study examines some difficulties of CL in the acquisition of French intonation. In this study, three basic French intonation patterns (according to Di Cristo 9: final neutral declarative, polar question with "est-ce que" and major continuation) produced by seven CL with different levels of proficiency in French are analysed and compared with the productions of six French native speakers (NS).

In the field, approaches and models for the description of the French intonation system are plentiful: ten basic French intonations of Delattre 6, intonosyntactic theory of Di Cristo 7, prepositional theory of Martin 14 and autosegmental-metrical theory of Jun & Fougeron 11. In contrast, not much descriptive research exists for Chinese intonations; we only have a list of 13 intonation types established by Chao 3. In Shen's recent model on the Chinese intonation system 16, 3 general patterns in Chinese speech are proposed (Tune I, Tune II, Tune III).

Since Mandarin Chinese is a tonal language, the interaction between lexical tones and intonation is also an important factor in acquisition of French L2 intonation. However, to our knowledge, a study on how lexical tones influence Mandarin speakers acquiring non-tonal language's intonation has not been found. Among all the studies on phonetic crosslinguistic transfer from Mandarin Chinese to French, the majority of them investigated segmental transfer. There are only a few studies on suprasegmental transfer 4,12,13. According to this research, the main challenges in intonation production are steep slopes in rising and falling contours, lack of variation in F0 and lengthening in stress group. Perceptually, CL have no problems in distinguishing between rising and falling contours 10,15. The goal of the present paper is to examine productions of the three basic French intonation patterns using acoustic and perceptive measurements, in order to determine the problems and difficulties in CL of French as a Foreign Language (FFL).

HYPOTHESES

Based on the conclusions in previous research and our empirical observations from the recording experience, we have come up with several hypotheses for this study: i) final neutral declarative: CL realize a falling contour and slope, but the slope will be monotone or discontinuous; ii) polar question with "est-ce que": rising contours produced by CL will be the same as what they produce in polar question without a marker; iii) major continuation: there will be a mix of rising and falling contours in CL' productions; a falling contour as in the case of final neutral declarative contour, and a rising contour as in the case of polar question.

METHODS

Speakers and corpora

Seven female CL of FFL (mean age: 25.43, SD: 4.95) with varying levels of proficiency in French (1 learners with a level B1, 3 with B2, 2 with C1 and 1 with C2 according to the Common European Framework of Reference for Languages) took part in the recording experience. All CL speak Mandarin Chinese as their mother tongue, started learning French as adults (between 2 and 6 years), and had been living in France for at least two years at the time of recording. Six female Parisian French native speakers (NS) (mean age: 24.6, SD: 1.14) participated as references for perceptive stimuli and acoustic comparisons. The recording took place in a sound proof room. Participants were recorded one by one, using Pro Tools program, with an AKG C520L wireless head worn microphone (distance mouth-microphone: 3 cm) and a sound card MOTU ULMK3. The corpora included 10 French sentences (four of them contained major continuation) and each of the 10 sentences had three different intonation modalities: final neutral declarative, polar question without a marker and polar question with "est-ce que". Totally, we had 30 sentences in the corpora. All participants were asked to read the corpora with a natural tone.

Perceptive study

To examine and compare intonation productions between CL and NS, two perception tests, which were destined to polar question with "est-ce que" and major continuation, were implemented with ten French listeners (each test with five listeners) on Praat 1. The stimuli for the test of polar question with "est-ce que" were manipulated by a truncation: we removed the syntactic question marker "est-ce que" and remained the part behind the marker for perception. For example, "Est-ce qu'il est joli ?" becomes "Est-ce qu'il est joli ?" in our test. The same method, a truncation, was also used to manipulate the sentences with major continuation: the part following the major continuation was removed from the sentence: "Vous aimez l'anglais et vous étudiez la littérature." becomes "Vous aimez l'anglais et vous étudiez la littérature.", for example. In both tests, French listeners were requested to choose between "Affirmation" and "Question" according to what they have heard.

In our perception tests, choices made by each listener were collected and gathered to be compared and analyzed by t-test in R statistical computing software 18: in each test, for the "affirmation" responses, we calculated the p value between CL' and NS' productions. The same method was also used to the "question" responses.

Acoustic study

After the perception tests, an acoustic analysis was performed, using quantitative and qualitative methods. Quantitatively, i) values of F0 beginning (point at 10% of stress group, for example "joli" in "il est joli?") and F0 ending (point at 90% of stress group) were generated by a script, whose differences (converted into semi-tone with 200 Hz as reference: F0-Diff) allow to determinate a rising/falling contour; ii) range of F0 variation in the whole stress group were also calculated. Qualitatively, melodic contours were generated by Praat 1 in order to compare them with NS' realizations. We chose several most typical examples to show here.

RESULTS

Perceptive tests (identification)

Test 1: polar question with "est-ce que"

After the comparison for the polar questions with "est-ce que", CL' productions were usually perceived as "question" (figure 1 right) whereas NS' productions were mostly perceived as "affirmation" (figure 1 left). By unpaired t-test, we found that the productions of polar questions with "est-ce que" by CL and NS were significantly different ("affirmation" responses: t5=7.24, p < 0.05; "question" responses: t5=-8.29, p<0.05).

Test 2: major continuation

The same procedure was applied to major continuation. It was established that, for this pattern, NS' productions were mostly perceived as "question" (figure 2 left) whereas CL' productions were usually perceived as "affirmation" and "question" (figure 2 right). By unpaired t-test, productions of major continuations by CL and NS were shown to be significantly different ("affirmation" responses: t5=-4.16, p < 0.05; "question" responses: t5=5.44, p<0.05).

Acoustic analysis

Polar question with "est-ce que"

After F0-Diff values, all CL produced a rising contour. However, the difference and the range of F0 variation almost had the same values as in polar question without a marker. However, among the NS, both F0-Diff and F0 range were smaller in polar question with "est-ce que" than in polar question without a marker. An example of productions of "Il est joli ?" vs. "Est-ce qu'il est joli?" is provided in Table 1. We can clearly see that among NS, a polar question with "est-ce que" had a much smaller difference than in a polar question without a marker, which was totally opposite to CL' productions. Qualitatively, by melodic contour in stress group, we showed that CL's slope went up as high as in the polar question without a marker (figure 3, left) whereas, NS's slope kept as a plateau in the polar question with "est-ce que" (figure 3, right). This difference in polar questions gives an explanation as to why the NS' productions were mostly considered as an affirmation but not a question while the CL' productions were mostly considered as a question but not an affirmation in our perception test 1 (see 4.1.1.).

Major continuation

After calculation of the F0-Diff, our hypothesis has been confirmed: in some productions of CL, rising and falling contours were mixed. A falling contour was the same as in the final neutral declarative and a rising contour was similar to a contour in polar question. First, three CL' falling productions (table 2) is provided below as examples to compare the F0-Diff and the F0 range with three NS' productions: Qualitatively, productions of NS were characterized by a falling contour at pretonic syllable and a small rising contour at tonic syllable. In CL, this was characterized directly by a steep rising slope (figure 4).

Final neutral declarative

All our CL produced a falling contour in this modality. Though falling, qualitatively, it always was a plateau in whole sentence. In contrast, the contour in NS has a bigger F0 variation and a progressive and gradual falling contour at stress group (figure 5). According to our calculation, we concluded that "est-ce que" question is a problematic pattern for all CL, except the one with C2 level. For major continuation, it is a difficulty for the learners of intermediate level.

DISCUSSION AND CONCLUSIONS

In this study, we have examined three basic French intonation patterns learnt by CL. In our perception tests, we have found a significant difference in the productions of polar questions with "est-ce que" and major continuations by NS and CL. After that, acoustic measurements have detailed the problems of CL in French intonation learning: i) polar question with "est-ce que": in CL' productions, they didn't distinguish different rising contours for polar questions with a marker from without a marker. But, quantitatively, in "est-ce que" questions, NS' productions had a smaller F0-diff and a smaller F0 range than in a total question. Qualitatively, in CL' productions, the rising contours in these two modalities reached a same level while NS' contours had a higher lever in total question but a lower lever in "est-ce que" question. We suppose that in a language, when speaker produces a question without a marker, melodic variation would be more evident; when a question marker is present (e.x. est-ce que for French, ma for Mandarin Chinese), melodic contour would not have a big variation. It is the reason why NS' "est-ce que" question contours had a quasi-plateau. For native Chinese speakers, it has been also proved that question without a marker has a bigger F0 variation 19. We may consider that the marker "est-ce que" for CL has not been interiorized; ii) quantitatively and qualitatively, a mix of rising and falling contours were appeared in CL' major continuations: a falling contour when the sentence is declarative and a rising contour when the sentence is interrogative. We consider that CL have been influenced by sentence modality; iii) in final neutral declarative, our analysis has confirmed the conclusions in the work of Chi Lee 4. CL' productions were characterized by a plateau or a steep slope, as concluded by Chi Lee 4. We suppose that lexical tone 1 (high, constant) of Mandarin would influence CL' French declarative production, which is manifested by a series of tone 1 without melodic variation in their productions. Thus, CL' productions were said to be monotone.

However, there are several limitations with this present study: i) F0-duration interaction should have been studied in our analysis; ii) influences of lexical tones on French intonation acquisition remain until now unknown. In our further research, these factors will be taken into consideration.

Figure 1 :

 1 Figure 1: identification percentage of polar question with "est-ce que" produced by NS (left) and CL (right).

Figure 2 :

 2 Figure 2: identification percentage of major continuation produced by NS (left) and CL (right).

Figure 3 :

 3 Figure 3: F0 contours in polar questions without and with a marker: CL3's production (left); NS4's one (right).

Figure 4 :

 4 Figure 4: comparison of two melodic contours of major continuation produced by CL4 (left) and NS6 (right).

Figure 5 :

 5 Figure 5: comparison of two melodic contours of final neutral declarative produced by CL2 (left) and NS5 (right).

Table 1 :

 1 F0-Diff and F0 range for NS and CL in the production of polar questions with/without a marker ("Est-ce qu'il est joli ?"; "Il est joli ?", Unit: semi-tone).

	Speaker(level)	Pattern	F0-Diff (st)	F0 range (st)
	NS1		+2.1 / +7.3	6 / 10
	NS2		-1.2 / +9.8	2 / 11
	NS3	Polar Question	+2.2 / +8.4	6 / 14
	NS4	with the Marker	-0.1 / +9.3	4 / 11
	NS5	"est-ce que"	+3.7 / +8.9	5 / 11
	NS6 CL1 (B1)	/	+3.3 / +7.6 +9.1 / +10.6	5 / 10 12 / 12
	CL2 (B2)	Polar Question	+8.3 / +8.7	13 / 12
	CL3 (B2)	without the	+6.3 / +5.6	9 / 8
	CL4 (B2)	Marker	+10.5 / +12.5	12 / 12
	CL5 (C1)	"est-ce que"	+5.4 / +6.4	8 / 9
	CL6 (C1)		+6.1 / +7.8	8 / 18
	CL7 (C2)		+10.1 / +0.9	2 / 12

Table 2 :

 2 comparison of falling contours between final neutral declarative ("Il a parlé du paysage.") and major continuation ("Il a parlé du paysage, et de tout autre chose.") for CL and NS. Unit: semitone (st).

Second, for this pattern, when CL produced a rising contour, quantitatively, it was the same as with NS' productions, except that NS' productions had a smaller F0 range in major continuation than in polar question without a marker, but we had the same F0 range in both of the two patterns in CL (table 3).


Introduction

This paper discusses a generic telematics systems based on the OMAP™ (open multimedia application platform) heterogeneous ARM™/DSP multiprocessor system. These 2 processors are integrated as SOC (system on chip) with a peripheral mix dedicated to the automotive requirements as a one chip solution. These processors are able to run parallel various real time applications optimized either for the DSP or the ARM-RISC processor or shared between both processors.

Automotive radio and navigation systems require high integration and flexibility through programmability. High integration provides cost and space optimized solutions. Programmability allows adaptation of the software for new developments in algorithms and standards. Low power consumption is another important requirement and concern of system architects. Application optimized processors and high integration is important to fulfill all these requirements.

Telematics applications have to deal with several audio sources, have to drive several audio amplifiers and require an easy interface to the user, usually the driver of the car. Several real time applications have to run in parallel, like the HMI (human machine interface), either based on traditional radio-button based interfaces or on voice recognition.

The OMAP™ dual core processor addresses all these issues with various optimized interfaces for analog, audio and digital data sources and sinks. The ARM™ processor, driven from validated automotive operational systems controls the system, and dynamically loads the required algorithms to the DSP. The DSP is optimized for audio and codec functions and able to react as real time processor to the various data streams.

Heterogeneous DSP/RISC solutions, with application optimized peripherals built as SOC, will be key for many applications. These solutions combine both high performance DSPs and standard RISC processors. Standard operational systems can be used. This allows fast time-to-market as many 3rd party software products can be easily integrated.

A simple definition of Telematics

In modern cars it is required that the driver information is integrated in the environment of the car. Telematics is the name for such solutions. It involves the convergence of consumer electronics, computing, and communication in the vehicle. Navigation, digital radio, Internet, multimedia entertainment, reconfigurable displays, wireless access, and other applications are driving the need for advanced electronic components in the vehicle.

Considerations for a Telematic system

A Telematic system is the integration of radio, navigation and communication into 1 system. The navigation system is based on a GPS (global positioning system) module providing the location information. In the future the new European Galileo system will provide even better and more precise location information. The coordinates provided from the navigation system is correlated with mapping data from a CD or DVD. This allows calculating the best route based on the location of the car and the available data. The problem with this solution is that the data on the CD is usually not in an actual status. It cannot take into account the traffic situation, like density of traffic on the various routes, accidents and traffic jams can quickly change the situation. A dynamic system has to take these circumstances into account. Dynamic data for continuous update can come from various sources. Today analog radio provides regular traffic information, but there is no link to the navigation system, except that the driver can actively take the traffic information into account. Another disadvantage is that the traffic information is broadcasted for a large area, therefore the necessary data comes quite often not precise enough and without recommendation for other routes. Digital Radio will change this in the future. Data can be transmitted to the car very precisely and directly to the navigation computer. This will help to quickly develop alternative routes to recommend to the driver.

GPS

Generic information about road constructions on certain routes and updated road information in general can come via a mobile phone as an update to a CD on regular basis. A modern Telematic system has to integrate all these aspects. The GPS based navigation system provides the location information. This data is correlated with the mapping information stored on a CD or DVD and updated with actual information coming via digital radio and a mobile phone data channel. Based on this data and the planned destination of the journey the navigation computer can calculate to optimal route. If new data coming in suggest a change due to traffic jam, an alternative route can be calculated and suggested. As the driver should not work with the navigation system while driving the interface between the navigation computer and the driver has to be done via speech. A modern Telematics system has therefore to include good speech synthesis software with speech recognition. Such a system can establish a dialog between the driver and the navigation computer in order to find the best route under actual traffic situations to the planned destination.

Other applications for a Telematics system

The Telematics system has to be more than a navigation computer. As already discussed it has an interface to the digital radio and the GSM phone. This includes of course that the necessary audio stream to the speaker in case of the radio, or the microphone and a speaker for the mobile phone will be routed through the navigation computer or Telematics system. This required that the HMI (human machine interface) for all radio, mobile phone and navigation based functions have to be done from the same system.

Audio streams sources are CD-DVD player, flash memory cards, radio tuner, or the microphone for the mobile phone. These sources have to be routed to the speaker.

In future systems also video streams have to be routed through the same system to provide either video from a DVD player to the rear seats in the car. In this case the audio data might be different in the front and rear of the car, so that 2 stereo audio streams are required.

OMAP, a programmable solution for adaptable applications

The previously described system requires that a very flexible and configurable system. It is impossible, that a dedicated hardware solution or an embedded processor runs all these applications in parallel. Additionally it has to be taken into account that new codecs might be defined and the system has to be flexible enough to adapt these new algorithms. This is only possible with a software programmable solution. OMAP (open multimedia application platform) is an answer to these requirements. It contains 2 processors which are optimized for different applications. Common interfaces to the outside world allow the different input data and audio streams to be loaded into the processors. After processing the data various data sinks route the data to the speaker or display. Of course also the OMAP processor system cannot run all the applications concurrently. Therefore the actually required algorithm is loaded to the right processor, if possible into the internal memory or cache. OMAP is originally developed for the mobile market. Also here different algorithms and applications are required. For HMI and data management functions, which usually have to run on a standard operational system, a RISC processor, like the ARM926 is the optimized processor. Many operational systems, like Windows CE .NET™, Linux , Nucleus™and VxWorks™, Symbian™, QNX™, and many more exist for this processor platform or are in development.

Audio streams, calculation intensive algorithms, e.g. in GPS, codecs with various decoders like MP3 and MP3Pro, MPEG I+II Layer 2, MPEG II + MPEG IV AAC, WMA, AC3, ADPCM are best suited for a digital signal processor. Therefore a TMS320C55x core has been integrated into OMAP.

OMAP™ Application Partitioning Example

The following example illustrates the partitioning of an OMAP processor for speech applications as HMI application as it is required in Telematics systems. Information from the system is provided via Text to Speech while commands from the user are taken via speech recognition. The DSP does the pre-and post-processing. These require typical digital signal processor algorithms, like filtering to reduce the noise etc. In multitasking the DSP continues the processing of the audio streams, the radio and GPS functions. The ARM processor does the grammar parsing and acoustic models and is also responsible to search in the large external vocabularies to find the right match. On the ARM a typical operating system is executed while on the DSP the DSP/BIOS operating system is used. The reference frame work provides the necessary functionality to exchange data between both processor cores, and of course the run the required applications on the DSP, controlled from the ARM processor.

Unified Recognition and Text to Speech Architecture

Both processors provide the right mix of features to allow optimized execution of the various applications. Together they form a heterogeneous system with with following portioning:

• ARM is system master and controls the system resources:

Evolution of the OMAP architecture

The OMAP architecture has its origins in TI's 2G wireless baseband devices, originally based on an ARM7 MPU and C54x DSP as a power-efficient and adaptable solution, interfacing to GSM and various other mobile phone standards throughout the world. The new wireless standards 2.5G and 3G demand more processing performance, in order to offer capabilities such as 384 Kbps data transfers. In addition, wireless technologies like BlueTooth and 802.11 offer alternative and sometimes complimentary means of wireless data exchanges. The family of devices offered by the OMAP platform provides a common TI-enhanced ARM microprocessor and a collection of peripherals and memory interfaces. Additional multimedia performance is provided by a C55x DSP.

OMAP software Compatible Devices OMAP710 --------------------------------- --------------------- TI925 ARM MPU ARM MPU ---
The latest development is the OMAP5910, which is with some modifications the basis for other, application specific solutions. The next chip, the OMAP59xx will have dedicated automotive peripherals, e.g. a CAN interface. It will be based on an ARM926 RISC and c55x DSP processor kernel. This combination of computation power with the right mix of peripherals will provide the necessary performance for speech interface based radio navigation system as previously defined as a typical Telematics system.

OMAP Architecture Details

A general-purpose processor (GPP or MPU) runs applications under an operating system such as WinCE, Symbian, QNX and many others. Support for a variety of industry-standard operating systems provide the sophisticated development environments and allow reuse of software and experience for software teams. Standard programming interfaces (APIs) are called to perform a variety of multimedia and navigation operations. Depending on the complexity of the operation and available system resources, the API may perform the operation on the spot, offload it to a digital signal processor (DSP), direct a system direct memory access resource (DMA) to perform it, or make use of a custom peripheral such as security module. DSPs are ideal for performing mathematically-intensive real-time tasks such as MP3, AAC, and many others or even video decoding. DMAs automate the transfers of data from larger external memory to fast internal memory (and back), or between peripherals and memory, without requiring MPU or DSP intervention. Custom peripherals perform relatively simple, well-defined tasks extremely efficiently.

By delegating work to those most efficient at performing it, overall performance is enhanced, and power reduced by idling those resources not in active use. It preserves software compatibility while allowing for flexible tradeoffs between performance, power-consumption and system-cost. The use of a programmable DSP ensures adaptability to ever-evolving protocols, formats, and standards such as digital music. The GPP, DSP, and DMA could each be attempting to access memory, such as external SDRAM / Flash or internal video frame buffers, or the memory-mapped registers of peripherals. The Traffic Controller (TC) will arbitrate between these requests and direct simultaneous accesses on different buses to maximize data throughput for the system.

Integrated OMAP5910 Delivers System-on-a-Chip Functionality

To manage the offloading of tasks from the GPP to the DSP, software components such as multimedia engines utilize DSP/BIOS link, an TI-provided API designed to manage multiprocessor communications.

Examples of media engines are either available or in development include:

Software development for Radio Navigation Systems on OMAP

A developer would create an application to run under an embedded operating system, such as WinCE or Symbian Quartz. When function calls are made to an API such as a subset of OpenGL, the ARM MPU would collect the data and pass these buffers to the DSP engine, using DSP/Bridge to handle the details of allocating and managing the DSP resources used for this task. While the DSP takes care of the numerically intensive graphics algorithms, the MPU resumes executing the remainder of the game processing. This dual-processing model is similar to that found in a PC with a 3D graphics accelerator card. A variation on this approach is to have the ARM processor perform the geometry portion of the 3D pipeline, while the DSP performs the rasterization portion.

Code Composer Studio for OMAP Debugging

The OMAP Code Composer Studio (CCStudio) Integrated Development Environment (IDE) provides debug support for the OMAP platform via heterogeneous debugging of the ARM926 and TMS320C55x-based DSP subsystem cores, which are connected on the same JTAG scan path within the device. Simultaneous debug of two or more CPUs, sometimes referred to as co-emulation, allows the user to coordinate debugging between both of the processors. The Parallel Debug Manager (PDM) control within Code Composer Studio IDE can be used to execute the targets in parallel, i.e., stepping or running. It can also be used to configure global breakpoints. This feature allows you to designate both processors to halt when either processor halts. Global breakpoints and coemulation are very useful when trying to debug code that provides communication or signalling between processors.

This application report describes how to setup Code Composer Studio using the heterogeneous device driver, and how to start debugging an OMAP platform using the Parallel Debug Manager. Although some of the values will be different for other OMAP platforms, the process contained in this application report can be used as a framework for those devices.

Summary

TI's OMAP architecture provides the programmable solution necessary to address the ever-changing landscape in Telematics Radio Navigation systems. As the requirements continuously increase (better graphics, sound, performance), software will need to run on a range of platforms at different price points, and preserve the software development investment across several generations of products. The OMAP architecture provides a framework where flexible software components can be used across different OSes and devices, providing additional features and performance in a backwards-and forwards-compatible manner.

I2S I2C OMAP5910 System Diagram High Performance, Integrated Speech Radio PA Radio Interface Audio RDS Dec SRAM/ Flash SDRAM LCD Display & Bezel Audio CODEC, Touchscreen Controller & Power Management OMAP5910 ARM925 (incl MMU) Traffic Controller & EMIF C55x DSP Bluetooth and/or Wireless Modem Other Interfaces • USB • Camera/Video • SD/MMC/SPI • Digital Radio • CompactFlash CD/DVD

  Because of the programmable and open nature of the OMAP architecture, new media engines can be developed by anyone, and DSP/BIOS Link helps ensure that multiple media engines can coexist.

	• Audio: MP3, AC, WMA, RealAudio, and MIDI • Video: JPEG, MPEG-4/263, GIF, JPEG2000, and RealVideo • Speech Recognition: Speaker independent or dependent, noise suppression, echo cancellation. • Security • Location-Based Services • Vocoders: AMR

RM Server CORE RUN-TIME SUPPORT I/O AND COMMUNICATION GPP OPERATING SYSTEM Bridge Software Architecture CD Loader VEH BUS Mobile Phone / BT Radio Display GPS IDE Mic / Array other H/W

	• Media Players
	• User Interface
	•Connectivity
	• Productivity
	• • •
	Media Engine Modules
	speech	audio	video
	REAL-TIME TASKS
	DPS/BIOS™ KERNEL
	LINK driver	other drivers

-22 -23 January 2004


The high-redshift dusty Universe

❖ Final frontier in piecing together a coherent picture of cosmic history relates to the period 6<z<15

❖ Earliest stars and galaxies began to shine ❖ The intergalactic medium transitioned from a neutral to a fully ionized gas ❖ The two are connected (e.g., Planck collaboration 2016, Robertson+2015)

❖ Another remarkable result :

❖ Realization that the SFR at redshifts z>1 is higher than at present by about an order of magnitude ❖ >half of the energy produced since the surface of last scattering has been absorbed and reemitted by dust (in Dusty Star-Forming Galaxies, DSFG)

Madau & Dickinson, 2014
The high-redshift dusty Universe ❖ Two fundamental questions AtLAST has to address:

❖ What is the contribution of the dust-enshrouded star formation at z>3?

❖ What is the role of DSFG in shaping the reionization?

❖ In particular:

❖ When did the Universe produce dust? What is the history of star formation?

❖ How the ISM in typical galaxies matures from a nearly primordial, dust-free state at z~8 to the dust-and metallicityenriched state observed at z~4?

❖ From gas to stars: what are the processus of regulation of starformation?

Observing the high-redshift dusty Universe Observing the high-redshift dusty Universe ❖ In the (sub-)mm, galaxies are so faint and numerous, compared to the angular resolution achievable, that confusion plagues observations substantially.

❖ Limited to the brightest galaxies ❖ This corresponds to a SFR-limit of: 9 M ⊙ /yr at z=2 30 M ⊙ /yr at z=4 92 M ⊙ /yr at z=6 (for >5σ detections)

❖ BUT, very hard to reach confusion limit on large patches at this wavelength AND not optimal at z>4

Simulation assuming a 25-m and no instrumental noise

SFR limit versus telescope size (for a 850 μm survey)

❖ Negative K-correction: similar SFR limit for z=2-6.

❖ From 25m to 50m: confusion limit 5 times lower.

❖ 40-50m: able to detect the obscured SFR of the typical LBGs (a few tens of M ⊙ /yr)

❖

  Béthermin+2017: clustering + low-angular resolution: ❖ Number counts measured by Herschel at 350 and 500!m between 5 and 50 mJy are biased towards high values by a factor ∼2 ❖ Blind surveys with the ALMA interferometer can see fainter DSFGs but are detecting only a handful of galaxies at z>4 because of its limited mapping speed. => High mapping-speed continuum and spectroscopic galaxy surveys with a large single-dish telescope Confusion-limited survey with a 25-m dish at 350 microns ❖ Confusion noise = 105 !Jy RMS (after excluding 5σ sources)

❖❖❖❖

  2D and 3D intensity mapping ❖ Large-scale spatial fluctuations on the collective emission from all the sources emitting in one frequency band (2D) or in some convenient spectral lines (3D) ❖ 2D: Cosmic Infrared Background anisotropies ❖ Herschel and Planck (Viero+13, Planck collaboration +11, +13) ❖ Problem of degeneracies as N(z) is unknown, hard to isolate the highredshift signal ❖ 3D: bright lines (HI, CO, Lya, CII) ❖ Redshift information is retained (δυ ~1GHz) ❖ Low-angular resolution redshift surveys (confusion limited) ❖ CII: one of the brightest emission lines in the spectra of galaxies, extinction free tracer of star formation, redshifted into the relatively transparent submillimeter and millimeter atmospheric windows for 4 <z<9CONCERTO (CarbON CII line in post-rEionization and ReionizaTiOn epoch) ❖ Focal plane: ❖ KIDS, following the success of the NIKA2 IRAM camera ❖ Cooled to 150 mK thanks to a closed-circle 3He-4He dilution cryostat ❖ FOV D~15', fλ sampling => two arrays of 1,500 pixels ❖ Frequency range: (150)200 -360 GHz ❖ Martin-Puplet interferometer (like a Michelson interferometer but with a movable mirror) ❖ Spectral resolution (ν/δν): R=100 to 300 At least one spectrum for all pixels of the matrix every second ❖ CONCERTO @ APEX: θ=20" for CII at z=5 Primary goal: CII intensity mapping and CII-bright emitting galaxy luminosity function at 4.5<z<8.5 + CO intensity mapping at z<2 But rich ancillary science, from the ISM of our Galaxy to the hot gas and velocity flows in galaxy clusters ❖ Testing the pathfinder (KISS instrument) and recent funding to quick start the instrument building Cover large areas, high mapping-speed (large FOV ~1 deg) ❖ Continuum surveys: ❖ z<3: 350 !m, D>25m, θ<2.5", confusion 1σ<105 !Jy/beam ❖ z>3: 850 !m, D>40m, θ<5.3", confusion 1σ<57 !Jy/beam ❖ obscured SFR of the typical LBGs at z=6! => High redshift dusty Universe: simultaneous 750!m, 850!m, 1.1mm, 1.3mm imaging ❖ Line surveys: Cover a wide frequency band ❖ ex: CII luminosity function at z>4 and CII in reionisation ❖ 1σ = 10 6 L ⊙ at z=7 => S δv = 0.8 Jy km/sec ❖ @238 GHz (i.e. CII at z=7 ) ❖ R=750 => δz=0.01 & δv=400 km/sec