Embedded software engineer

Personal project 2017

Mar. → now

The Legend of Ina (Munich ) development of a tutorial/game around the GDB debugger to be used as training material in coredump analysis.

Professional Experience at Harman

Personal project 2015

Professional Experience at Bosch

Personal projects 2013-2014

April → May 2014 (2 months)

personal (Ludwigsburg ) FPGA configuration using a microcontroller. Studied the low-level (bare metal) functionning of the Xilinx Spartan 6 LX9 FPGA (esp. bitstream encoding, and internal routing configuration). Written C code for the STM32 F103 microcontroller (ST Microelectronics). See the blog of the project. Created a protocol for FPGA Live Reconfiguration. See the FLR protocol specifications.

Sept. 2013 → Feb. 2014 (6 months)

Technology&Strategy Engineering (Strasbourg , remotely) Proposed and supervised an internship for creating a USB/CAN tester solution. Supported the trainee in the development of a CAN driver according to the Autosar 4 specifications, and supervised the design of a USB driver for a ST Cortex-M4-based development board: Olimex STM32-P407. USB High-Speed using integrated PHY. 100% open-source devel. environment: GNU GCC, OpenOCD, Eclipse. Created the corresponding hardware board as a personal project. (KiCAD)

Internships and training

November 2011 (3 weeks)	Alstom SA (Belfort ) TCMS (Train Control and Monitoring System) training at Alstom Belfort. Acquired knowledge about Alstom embedded architecture, methodology and ControlBuild experience, and Rational ClearCase/ClearQuest.  more details
April 2010 → Sept. 2010 (6 months)	Kitagawa Data Engineering laboratory (Tsukuba ) Performed research into XML query processing using GPGPU. Studied about low-level GPU features for general purpose computation, which involved extensive usage of the CUDA toolkit on both Windows 7 and GNU/Linux. Developed sharp debugging skills with this toolkit. Excerpt of the abstract: The purpose of the research [..] is to evaluate the possibility of using General Purpose Graphic Processing Unit (GPGPU) to handle this task. GPGPU is a recent creation which gather research attention because of its large diffusion and cheap price. GPGPU is the result of the evolution of GPU coprocessors toward more flexibily and programable features in visual rendering. The latest features of these chips enable them to be used as stream processors. Stream processing is a highly data parallalized task in which a series of operation is applied to each element of a data set (a stream). Created a multiplatform datastructure for CUDA.  more details
Sept. 2007 → February 2008 (6 months)	Basel-Mulhouse airport (Saint-Louis /) intern on the IT staff. Managed the whole project life cycle: design, development, software release, documentations and users’ training. The software is now used by airline companies to update information screens at the airport terminal. The project made use of PHP, Apache2 and Oracle on HP-UX. Created a documentation system which allows to dynamically quote the actual source code in the devel. documentation.  more details

Languages

French	Native speaker
English	Advanced level in written and oral English Scored 955/990 for the TOEIC certification in January 2011.
German	Intermediate level Currently living in South Germany since February 2012.
Japanese	Courses in both France and Japan at beginner level Spent two six-month periods living in Japan. Currently learning the Japanese Kanjis: 400/2000

Skills

Harman International
Inatech, Garching, Germany

Engineer in the Navigation team (in collaboration with BMW CarIT).

Mission

1. Develop software components of the navigation controller, which makes the link between the user interface (made by BMW) and the navigation core (made by Harman).
2. Analyze (debug) malfunctions of the navigation system on tight schedule (esp., application crashes).
3. Review software changes and support other developers (Harman and BMW).

Objectives

The navigation controller is used in different variants of the BMW navigation systems (Europe, US, Asia, ...) developed by different suppliers, therefore the controller needs to comply to BMW project architecture.

The main objectives are to develop the controller following BMW guidelines and build an overall understanding of the navigation system so as to leverage this knowledge during performance and crash analysis.

Realizations

• Developed software sub-components: Persistency and ECU Coding. Coding style is based on C++11 features, strongly asynchronous design and template metaprogramming.
• Designed unit-tests.
• Wrote Doxygen documentation and Wiki pages including state-machine and sequence diagrams. Reviewed code from BMW developers.
• Analyzed coredumps using the gdb debugger. Developed custom tools to ease debugging/reviewing (e.g., pretty printing, state-machine extractor). Debugged rare cases and low-level issues.
• Analyzed DLT traces.
• Proposed a solution to reduce build time by introducing a distributed build option in the compilation scripts (build time is almost divided by two using two workstations).
• Built navigation software with custom SDK/interfaces.
• Flashed prototype hardware, reported/solved integration issues in both real and virtual targets.

Result

Embedded software component with tests and documentation.
Extensive experience of C++ debugging with gdb (both local and remote on virtual or real targets) as well as CommonAPI/SomeIP trace analysis.
Developer knowledge of the BMW project environment, toolchains and coding guidelines.
User knowledge of the Harman project environment, toolchains and navigation core architecture.

Contacts

• Hadi Mazzawi (CPM BMW Navigation)

References

• Genivi, Reference architecture
• Harman and BMW, Press release

Personal project, continued
 

Mission

Design a demonstration hardware plateform to study live FPGA reconfiguration. Show that reconfiguration can be achieved in a time window compatible with realtime usecases.

Objectives

Enable reconfigurations at the maximum clocks defined by the FPGA maker: 16-bit parallel bus at 50MHz.

Realizations

• Imagined a modular solution entailing enclosure, wiring, connector types, parts availability limiting the number of suppliers, PCB space limitation according to the chosen layout, chip package and pinout...
• Designed a configuration bus between the STM32 microcontroller external memory interface (FSMC) and the Spartan-6 FPGA parallel configuration interface (SelectMAP).
• Created the PCB layout and missing footprints in KiCAD.

in progress

Result

PCB design skills for compact "all SMD" microcontroller and FPGA boards.
Hand soldering skills including "thin quad flat pack" (TQFP) up to 144-pin (0.5 mm pitch), SMD parts up to 0402 footprint, and track length matching.

Robert Bosch GmbH
Technology&Strategy, Tamm, Germany

Engineer in Electric inverter software design team.

Mission

1. Design a continuous integration system based on Jenkins and compatible with the IBM Jazz lifecyle management tool.
2. Carry out runtime measurements: analyze the task scheduling, generate CPU runtime usage reports.

Objectives

Put in place a continuous integration server, targeting a move toward Scrum (agile) development methodology. The continuous integration server aims at finding any regressions (e.g., compilation errors, missing symbols, ...) as fast as possible after the developer committed changes to versionning system (enabling Scrum-style short-cycled deliveries).

Generate reports of the task scheduling and CPU load during runtime in realistic drive cycles in order to validate the hard realtime constrains are always met when the software is delivered to the customer.

Realizations

• Analyzed current sequence and tools involved in the complete build of the software of a inverter project at Bosch.
• Installed and configured a Jenkins continuous integration server in a Microsoft Windows 2012 virtual server environment.
• Contacted and gathered information about the opportunity to use command-line interface for each build step (e.g., automated source code generation from ASCET model files). Required a such interface when missing and supervised its development.
• Designed a Jenkins build sequence, enabling build steps to be run in parallel and on different virtual Jenkins slave servers whenever possible.
• Written Python script to automate Windows tools over COM interface when required.
• Written Wiki documentation about the design choices and common questions from the developers.
• Written Python scripts to automate the testbench (calibration and flashing).
• Designed further integration steps in order to run automated tests on the target in a real hardware in the loop environment (with physical simulation of a real vehicle).

• Generated runtime measurements using SMART after ensuring that the software runs in realistic drive cycles in the testbench.
• Made runtime measurement in the customer testbench at BMW facilities in München, and analyzed combined Bosch and BMW task scheduling as well as CPU load.

Result

Solution for an all automated build of the inverter software and first steps of automated tests on real hardware.
Experience of the Scrum development methodology in embedded environment.
Knowledge of each step of the complete build sequence from ASCET model files to running automated basic functionality tests on the prototype hardware in a Labcar environment.
On-site support of the customer (BMW) in its integration of the Bosch inverter.

Contacts

• Heußer Johannes (GS-EH/ESS1) concerning the continuous integration.
• Gillot Guillaume (GS-EH/ESS1) concerning the runtime measurements. LinkedIn profile

References

• Jenkins, Server Java API, javadoc.jenkins-ci.org
• IBM Jazz, Plain Java API, downloadable at jazz.net
• ETAS ASCET and INCA, COM APIs
• PLS UDE, COM API

Personal project
 

Mission

Evaluate the possibility of dynamic partial reconfiguration of the Xilinx Spartan-6 FPGA, in other words, the possibility of changing the look-up tables, interconnection matrixes or multiplexers while the FPGA is active.

Objectives

The Spartan-6 internal configuration memory is not documented by Xilinx. The main goal was to understand this native bitstream. This capability enables a microcontroller to read-back the FPGA configuration, to change its content (LUT, routing, ...) and write it back to the FPGA (without stopping it).

The proprietary Xilinx ISE design suite is never involved in this sequence.

Achievements

• Created a JTAG hardware interface, able to connect to the Xilinx Spartan-6 JTAG configuration port. The microcontroller target is based on the ARM Cortex-M3 architecture (STM32F3).
• Specified a serial communication protocol for dynamic FPGA reconfiguration (FLR protocol, for FPGA Live Reconfiguration).
  See the specification draft here: https://vjordan.info/flr/
• Studied the internal FPGA architecture at silicium-die level: CLB, routing matrix, serializer/deserializer, IO buffers... and the corresponding configuration bits in the native bitstream, with the help of the FpgaTools project.
• Designed and implemented the embedded FLR server on the microcontroller target.
• Made reconfiguration-ready Verilog designs, and compared them to their static counterparts: advanced trigger, infinite/reconfigurable state machine.
• Made a first beta release of a reference test platform for people interested in the project. Chosen target: ARM Cortex-M3, 72MHz, 64KB RAM, 512KB Flash.

Results

Documentation of Spartan-6 internal configuration bits.
A Reconfiguration protocol specification and corresponding implementation.
An embedded solution for dynamic partial reconfiguration of the Spartan-6 LX9 FPGA.
Gained interest to FPGA reconfiguration with a good positioning in Google search results of the blog. Try this search: "Spartan6 configuration".

1. a FLR client sends requests to the FLR server over a serial connection: read_target, set_LUT, set_routing, ...
2. the FLR server listens for requests, works on its buffer copy of the FPGA configuration, and then generates a valid bitstream so as to apply those changes to the FPGA.
3. the FPGA remains active and is controlled by its JTAG port.

Note: the microcontroller can also be autonomous and generate its own requests, hence removing the FLR client, and achieving a real embedded solution.

References

• Vincent Jordan, FLRe project blog, https://vjordan.info/log/fpga/full-dynamic-partial-reconfiguration-sequence-on-xilinx-spartan6-lx9.html
• Wolfgang Spraul, FpgaTools, https://github.com/Wolfgang-Spraul/fpgatools
• Xilinx, Xilinx Spartan-6 UG380, http://www.xilinx.com/support/documentation/user_guides/ug380.pdf

Robert Bosch GmbH
Technology&Strategy, Abstatt, Germany

Engineer in Flash bootloader team.

Mission

1. Develop the core generic bootloader component for the Hyundai/Kai Motors product line.
2. Build the project development environment for early simulation and tests of the bootloader.

Objectives

The bootloader software is tailor-made for each customer according to their very own specifications for diagnostic communication and flash software, but the bootloader team is also expected to provide the customer with improvements and suggestions concerning any missing features or recommended behaviours based on Bosch extensive experience in this field. The core bootloader component is meant to be used for all the projects of one customer, which are based on the same specification, but run on different ECUs. Please refer to my previous experiences for a description of the features provided by the bootloader.

Realizations

• Analyzed the Hyunday/Kia Motors specifications, and checked its compatibility with current generic software component
• Raised a list of questions to be answered by Hyundai/Kia about unclear points found in the specifications, and decisions about free choices let to the supplier (Robert Bosch).
• Development of the core software component according to the specifications
• Built up the simulation environment for early testing of the component
• Fixed accuracy issue found in the simulation layer

Result

Initial bootloader core component (preview) matching Hyundai/Kia specifications (initially targeting radar ECU)
Understanding of a simulation layer architecture for embedded software
Knowledge of customer specifications analysis

Contacts

• Kuerbitz Michael (CDG-SMT/ESB3), group leader. kuerbitz.de
• Hanusa Manfred (CDG-SMT/ESB3), team leader. LinkedIn profile

References

• Hyundai/Kia Motors confidential specifications for diagnostic communications.
• Bosch (internal) generic specifications for diagnostic communication and flash update.

Robert Bosch GmbH
Technology&Strategy, Abstatt, Germany

Engineer in Flash bootloader team.

Mission

1. Design a PC-based tool for testing requests sent over CAN network
2. Integrate this tool to the Bosch integrated test framework

Objectives

The main aims was to design a simple tool, easy to automate, and with better performances than the previous one. Additional goals were to output a detailed error description when request failed, and to design a flexible interface to handle more complex tests.

Realizations

• Design of a flexible COM interface for diagnosis requests over CanTp
• Integration a C++ DLL to handle CanTp communications
• Development a command-line tool with Perl support scripts for seamless integration in existing test framework
• Benchmark of the performances in comparison with the previous Bosch tool, as well as the customer tools (e.g., Volkwagen and Porsche flashing tools)
• Design of a detailed log system producing CANoe-compatible files
• Documentation and user training
• Integration in Bosch test framework

Challenge and solution

Microsoft Windows Seven is no real-time operating system, and time critical operations cannot be guaranteed in C#. This flaw could produce misleading test failures related to response timeout on the tester side. Customized low-level task and process priorities, as well as garbage collector monitoring are used to leverage this issue and achieve soft real-time performances under Windows. In critical load conditions, delays might still appear and would be reported to the test logs (clearly showing that the tester is in fault, rather than the ECU).

Result

Test tool which outperforms the previous tool and reaches maximal CAN performances (approx. 250µs per frame @ 500Kbps)
Experience of C# development in the .NET framework
Experience of Microsoft COM interfaces and DLL

Contacts

• Kürbitz Michael (CDG-SMT/ESB3), group leader. kuerbitz.de

References

• AUTOSAR CanTP specifications
• Vector XL API driver

Robert Bosch GmbH
Technology&Strategy, Abstatt, Germany

Engineer in Flash bootloader team.

Mission

1. Build from scratch a complete bootloader project using AR4.0 software components from Bosch's collection
2. Pass all automated test for Bosch generic specification (application download, diagnosis requests)

Objectives

The bootloader software is real-time operating system with strong ROM size requirements. It features a communication stack, as well as a flash memory stack, but those components have to be heavily tweaked so as to save ROM space. The bootloader implements the diagnosis interface over CAN, providing the functionality of flashing a new application in a embedded device.

Realizations

• Integration of a bootloader starting from a prototype board with a microcontroller having an empty flash memory
• Creation for a build environment to automate each steps
• Evaluation of the bootloader performances (start-up time, CAN data transfer and flash write speeds, …)
• Tests of the bootloader according to the Bosch generic specifications

Unexpected challenge and solution

The set of AR4.0 components required for bootloader operation exceeds greatly the ROM size requirement of the bootloader. To address this issue, the bootloader has been split into independent pieces of code, and ROM compression was used to reduce the size of unused ROM areas. A customized start-up code unpacks those areas to RAM only when they are needed.
This strategy enables the bootloader to match its two strongest requirements: fast start-up to application, and limited ROM size.

Result

Bootloader for Freescale MPC5643L with configuration options to address different customer needs
Integration documentation for Autosar 4.0 components in bootloader context
Knowledge of the international norms for diagnosis in automotive environments

Contacts

• Kürbitz Michael (CDG-SMT/ESB3), group leader. kuerbitz.de
• Hanusa Manfred (CDG-SMT/ESB3), team leader. LinkedIn profile

References

• ISO 14229-1:2013 Road vehicles -- Unified diagnostic services (UDS)
  if you cannot access ISO norms, you can see Wikipedia for a summary: Unified Diagnostic Services
• ISO 15765-1:2011 Road vehicles -- Diagnostic communication over Controller Area Network (DoCAN)
• Freescale Qorivva MPC5643L Microcontroller - Reference Manual

Robert Bosch GmbH
Technology&Strategy, Leonberg, Germany

Engineer in Autosar BSW component development team.

Mission

1. Design the Bosch-specific SysPreInit component for early clock and C runtime initialization of the Renesas V850E2/Fx4 microcontroller
2. Develop a subset of the Mcu component from the Autosar 4.0 specifications

Objectives

Design SysPreInit and implement Mcu component together, in order to enable start-up and DeepStop sequences as well as wake-up for the Renesas FJ4 microcontroller. Those two sequences have to be highly customizable

Realizations

• SysPreInit
  • Specifications of the component and design (including design documentation)
  • Development in V850 assembly code and C of a start-up sequence for Fx4 microcontroller clock initialization and C runtime
    Note: this component replaces the Greenhills start-up library used previously.
  • Integration debugging and support in final customer projects (especially for clock settings)
• Mcu
  • Development in C-code of a subset of the Mcu component dedicated to sleep/wake-up following the Autosar 4.0 specifications
  • Integration debugging and support in final customer projects (especially for wake-up issues)
• for both components
  • Creation of a test environment on the reference Renesas development board as well as a test set matching the specifications
  • Archive of the component
  • XML user documentation
  • MISRA C-code validation (static analysis) and release process

Result

SysPreInit+Mcu components for Renesas Fx4 microcontroller used in customer projects
Knowledge of the component development and creation process at Bosch

Contacts

• Mohr Torsten (CDG-SMT/ESA1), team leader.

References

• V850E2/Fx4 User Manual
• AUTOSAR 4.0 Mcu driver specifications

Robert Bosch GmbH
Technology&Strategy, Leonberg, Germany

Engineer in BSW integration team.

Mission

1. Integration of Autosar-compliant operating systems (addressing both AR3.1 and 4.0 specifications)
2. Support of the clients with an overall knowledge of the basis software (BSW) for further OS-level customizations

Objectives

Customize and adapt a reference platform BSW into a project-specific BSW to match the client requirements. The BSW includes the real-time operating system and a set of components integrated so as to create an abstraction of the hardware target. Test and check all the major features in order to provide the client with a software layer ready to host an application. See AUTOSAR Basic Software at the the official AUTOSAR website for further details.

Realizations

• Customization of Start-up/Shutdown, Deep-sleep/Wake-up, OS timer and clocks
• Configuration of the CAN and LIN networking and the whole communication stack from the driver to the abstraction layer
• Configuration of the non-volatile memory and failure storage (aka “Memory stack”)
• Configuration of the RT-OS library (e.g., interrupt handling, tasks)
• Integration of smaller components such as Spi, Pwm, Adc, …
• Integration tests on development targets
• Analysis and report of the bugs found in the components
• Archive of the project into eASEE

Result

Integration of the basis software layer for ARM-based Xilinx Zynq and V850-based Renesas Fx4
Knowledge of the Autosar framework as well as Bosch methods for BSW generation

Contacts

• Moreau Jonathan (Bosch external, Technology&Strategy).

Robert Bosch GmbH
Technology&Strategy, Abstatt, Germany

Mission

1. Analyse and fix the testSuite of the diagnosis software (DSW) involved in the whole range of Bosch ABS/ESP products (from simpler ABS to full-featured ESP).
2. Analyse and design automated tests for the model-based sensors monitoring (MonAlgSim) required by ESP decision making.

Objectives

DSW validation of the functioning: check that all failures trigger the correct fallback mode according to the five kinds of generic configurations. Those configurations are customized for each client.
MonAlgSim development of the test pool: enable the validation of all sensor error generation using a Matlab simulation of the car physics. Those tests allow PC-simulated bug findings, i.e. before running the embedded software on the real target.

Realizations

• Diagnosis software
  • Added TestSuite support and fix the build process of 10 projects.
  • Analyzed all the test failures found by TestSuite.
  • Proposed code-fix or config-fix so as to avoid those failures.
  • Committed a new revision of the 10 projects with TestSuite support and fixes.
  • Wrote a documentation of the changes.
• Model-based sensor validation software
  • Gathered information about test design for the cutting-edge PC-simulated validation of sensor monitoring.
  • Wrote automated test for whole range of sensors (wheel speed, steering angle, inertial …) using inside knowledge of ESP software.

Result

Improvement of two validation processes through earlier bug finding in diagnosis and sensor monitoring
Knowledge of Bosch process for ESP software design

Contacts

• Parga-Cacheiro Luis (CC/ESM1), concerning the diagnosis software.
• Martin Uwe (CC/EVD5), concerning the sensor validation software.

Alstom transport
Alten, Belfort, France

Engineer in Train Control and Monitoring System team (aka TCMS team).

Mission:

Get developer-level knowledge of the TCMS platform.

Objectives:

Develop and train Russian developers (in English) at TRTrans, a joint-venture between Alstom transport (France) and Transmash holding (Russia). The JV is located near Rostov-na-Donau, Russia.

Training topics:

• Week 1
  • General introduction of train components and design requirements.
  • Detailed presentation of the embedded networks and processing units found in Alstom trains.
• Week 2
  • ControlBuild training performed by Dassault. CB is the software for design, simulation and generation of embedded software.
• Week 3
  • Alstom methodology and coding guidelines.
  • TCMS internal functioning and testing process.

Result:

Knowledge acquired about Alstom embedded architecture and generic knowledge about trains
Experience with ControlBuild 2010

Contacts

• Arnavon Brice (Alstom external, Alten). LinkedIn profile

Kitagawa Data Engineering laboratory
University of Tsukuba, Tsukuba, Japan

Ph.D. candidate in Computer Science

Mission:

1. Explore non-uniform parallelism on GPGPU
2. Design an algorithm for XML query processing that better fits GPU/DSP architectures

Objective:

Get faster queries/data-mining processing times over large XML documents through massively parallel execution using dedicated hardware.

Realizations:

• Research proposal for Ph.D. thesis ( Proposal)
  • Research articles reading related to XML parallel processing using Cell processor or FPGA.
• Study of the Fermi GPU architecture and OpenCL toolkit
  • OpenCL implementation of Staircase algorithm (C++ language) avoiding divergent threads execution so as to better match GPU/DSP computing architecture.

Result:

Implementation of Staircase algorithm customized for parallel processors such as GPGPU.

Contacts

• 北川 博之, Kitagawa Hiroyuki (KDE lab.), professor. www.kde.cs.tsukuba.ac.jp/~kitagawa/
• 天笠 俊之, Amagasa Toshiyuki (KDE lab.), associate professor. www.kde.cs.tsukuba.ac.jp/~amagasa/

Kitagawa Data Engineering laboratory
University of Tsukuba, Tsukuba, Japan

Researcher in data engineering using low-level GPU computing

Mission:

Carry out research during final project assignment in a research laboratory

Objectives:

Develop and evaluate the performance of GPGPU for query processing on XML documents

Realizations:

• State of the art study about query processing algorithms on XML documents
  • Research articles reading
  • CPU implementation of the TwigStack algorithm (C language)
• Study and writing of a simplified XPath parser
• tokenizer: flex, parser generator: lemon
• Study of Tesla GPGPU architectures and CUDA toolkit
  • Analysis of the hardware limitations of the Tesla GPU architecture such as the lack of cache memory (scratchpad only), no function support, no dynamic memory allocation, no pointer space protections, and the memory alignment issues depending on word size.
  • Design of a strategy enabling divergent threads execution so as to overcome lock-step thread execution scheme.
  • Creation of a development method for easier debugging by making use of massive code preprocessing which enables to target both CPU and GPU processors.
  • Creation of a dedicated library in order to overcome GPU hardware limitations especially the lack of function call support since the TwigStack algorithm is recursive (“homemade” stack).
  • GPU implementation of parallel TwigStack algorithm (low-level C/CUDA language with customized data structures and memory allocation)
• Benchmark and results presentation during seminar
• English master thesis writing

Results:

Reusable library for memory management and dynamic array allocation using customized datastructure
Design solution for non-uniform threads execution using GPGPU and my library
Implementation of a parallel algorithm for XML query processing with balancing feature for scattering workload on multiple NVidia GPUs and CPUs (hybrid execution)
Debugging method through CPU and GPU in-memory comparison after an identic execution
Master thesis ( Master thesis)

Contacts

• 北川 博之, Kitagawa Hiroyuki (KDE lab.), professor. www.kde.cs.tsukuba.ac.jp/~kitagawa/
• 天笠 俊之, Amagasa Toshiyuki (KDE lab.), associate professor. www.kde.cs.tsukuba.ac.jp/~amagasa/

Basel-Mulhouse airport
EuroAirport, St Louis, France/Switzerland

Engineer assistant on the IT staff managing the airport’s computer facilities

Mission:

Manage an upgrade project (whole “V” lifecycle) during a six-month internship

Objective:

A reliable PHP5 upgrade of the software interface for information screens in terminals (software dedicated to airline companies) and seamless transition from previous to new version

Realizations:

• Previous software analysis
  • Code analysis and information gathering about the information screens system
  • Users meeting so as to find feasible enhancements
  • Creation of the update strategy (critical software having to be available 24/7)
• Updated version development
  • New tools compilation (Apache2, PHP5 with Oracle plug-in for HP-UX)
  • Creation of several incremental versions and test cases
  • Meetings with public relation department about graphic guidelines
• Technical and user documentation writing
• Meeting with airline companies managers and starting production
• French users training

Results:

Software upgrade ready on schedule (Dec. 2007) and still in use now at EuroAirport (2011)
Safe transition from 1.0 to 2.0 version thanks to an incremental development planning
Documentation aiming developers of future updates

Contacts

• Dettmar Christophe (IT team), main database administrator.

Mario Paint

Childhood, Heidwiller, France