Alon Horn and Oren Ierushalmi Supervised by Mony Orbach Winter 2010 Final Presentation Implementation of an Engine Control Unit over Many-Core System

Intro Project's goal is to Implement an Engine Control Unit (ECU) over a Many Core System. The ECU code will run on plurality's HAL architecture (simulated).

Project Objectives Implement an Engine Control Unit (ECU) over a Many Core System. Understand Plurality's HAL Architecture. Write Parallel Code using Task Oriented Programming. Simulate the Code Using Plurality's cycle accurate HAL simulator. Achieve Fast, Accurate, Robust and Efficient system.

Code design considerations: Real time inputs and outputs. No operating system on the board. The code is divided into Tasks. Each core runs a single task repeatedly. Communication between cores is done through shared memory.

Four Stroke Engine Today, internal combustion engines, most commonly use a four-stroke cycle 1. INTAKE stroke: The piston descends from the top of the cylinder to the bottom of the cylinder, reducing the pressure inside the cylinder, forcing a mixture of fuel and air into the cylinder. 2. COMPRESSION stroke: With both intake and exhaust valves closed, the piston returns to the top of the cylinder compressing the fuel-air mixture.

Four Stroke Engine 3. POWER stroke: While the piston is close to Top Dead Center, the compressed air–fuel mixture is ignited. The resulting massive pressure from the combustion of the compressed fuel-air mixture drives the piston back down toward bottom dead center with tremendous force. 4. EXHAUST stroke: During the exhaust stroke, the piston once again returns to top dead center while the exhaust valve is open. This action evacuates the products of combustion from the cylinder by pushing the spent fuel- air mixture through the exhaust valve(s).

Engine Control Unit An ECU reads data from various engine sensors, processes them to calculate fuel injection pulse and spark timing, then sends back 3 control signals: Fuel pulse width. Spark timing. Stepper IAC – Idle air controller. ECU Engine Control signalsSensors signals

Project Top Level Project's Main Blocks: ECU Unit Sensors offline generator Outputs checker/ visualizer Inputs Outputs

Engine Sensors EGO – Exhaust Gas Oxygen feedback. MAT – Manifold Absolute Temperature. ATP – Atmosphere pressure. TPS – Throttle Position Sensor. CTS – Coolant Temperature Sensor. MAP – Manifold Absolute Pressure. CPS – Crankshaft Position Sensor. Sync Signal – sync signal from the distributor.

ECU tasks block diagram

Tasks description 1. Calculation units: RPM calculator – uses the internal clock and the CPS input to calculate & advertise RPM. Distributor – calculates the engine's state using CPS & Sync inputs. Degree estimator – uses RPM & distributor to advertise an accurate estimate of the engine's degree (in a 720 degrees full cycle). Sync Identify – supporting task that identifies sync input signal.

Tasks description (Cont.) Acceleration – supporting task that calculates rate of changes in the throttle sensor. Injection pulse width and timing – calculates, based on other calculations, the length and starting degree of the fuel injection pulse. Ignition advance – calculates the timing of the ignition spark. IAC – calculates the desired state for the IAC stepper assisting motor.

Tasks description (Cont.) 2. I/O units: these tasks assist the implementation of the ECU inside the simulator enviroment. Read task – a task that reads data files and saves the input sensors data into designated structs. Dup input – duplicable tasks in charge of updating an input's value. Injector, Ignition out – tasks that changes an output's value at a certain time / degree, according to the calculation of the respective calc tasks. Clock – generates a clock signal.

Tasks description (Cont.) 3. Verification units: These tasks are not part of the ECU, but were used for data collection to verify the Unit's behavior. Dup logger – duplicable tasks in charge of updating an output's value. Write task – in charge of writing the outputs' structs to files.

Testing & Collecting data Tests running, data generation, and data collection was automated. Set of scripts and C utilities:  Generating binary input files from text.  Running a subset or the whole set of tests on the simulator.  Obtaining the binary data output, translating it to text, make them Matlab friendly, then generating graphs.

Tests Tests were conducted to examine each of the system's functions, and its reaction to each input. The tests are designed to isolate each parameter's influence on the system. These tests are:  test_tps  test_accelerate  test_accel_TPS  test_MAP  test_CTS  test_EGO

Example results Test_map outputs:

Example results Test_map internal signals:

Example results Test_map inputs:

Example results Test_CTS outputs:

Conclusions As a concept, the HyperCore chip architecture might suit an implementation of distributed ECU. Most of the issues we faced in our work, came down to the fact that we used only a simulator. Task oriented programming is easy and convenient. An ECU is a highly parallelized system. However...

Conclusions Development Environment problems: Installation issues. Architecture differences between host & simulator. Cross-debugging. Simulator implemented abilities. HARDWARE REQUIREMENTS. A newer version of the simulator is now available, so some of it's issues might be solved.