Design Of An Engine Control Unit Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This project presents a DESIGN OF ENGINE CONTROL UNIT , in which different DIGITAL sensors are used to gather data from specific parameters of engine and then displayed to the user/driver of the car. It is basically the real time measurement and transmission of speed of car, engine coolant Temperature and the mass-air flow ratio through the filter of the car. In this system four PIC controllers with built-in CAN module are used as three different nodes, first, second and third node measure the physical parameters, then transmit digital data on CANBUS. The data from the 2 sensors is sent to the display node, where it is processed by the same controller and then displayed on the LCD. Transmission and reception of data is performed using CAN transceivers.

An engine control unit (ECU) is a type of electronic control unit that controls the fuel injection system, ignition timing, engine temperature, water level, pressure and the idle speed control system. The ECU also interrupts the operation of the air conditioning and controls power to the fuel pump (through the control relay). The ECU consists of an 8-bit microprocessor, random access memory (RAM), read only memory (ROM), and an input/output interface.

The Engine Control Unit or ECU is a designated computer that was developed to manage the engine control system. The ECU monitors and adjusts the air/fuel mixture and utilizes a catalytic converter to minimize the amount of pollution produced from the engine.


Before the advancement in technology and introduction of ECU in automobile, the car engine was controlled mechanically. However the Implementation of Electric Control unit on Engines has greatly improved the performance of the engines.

The Electric system in car engines has also made it environment friendly moreover it has ensured greater security of the passengers aboard on the vehicle.

For example the combustion of fuel and air mixture in the combustion chamber of the engines earlier used mechanically controlled carburetors which effected the performance of the engines, as the fuel did not burn thoroughly, which caused pollution in the environment. But ECU based Combustion system ensures the complete combustion of the fuel and air mixture thus increasing the efficiency of the engines and making them Environment friendly as well.

The ECU monitors the input and output signals produced by various sensors in the system. The ECU then adjusts the system as necessary. Sensors can include: coolant sensor, mass air flow sensor, air intake sensor, throttle position sensor and camshaft angle sensor.

It is based on information from the input sensors (engine coolant temperature, barometric pressure, air flow, etc.), the ECU determines optimum settings for the output actuators (injection, idle speed, ignition timing, etc.).

In our project we will use Controlled Area Network (CAN) bus protocol. CAN bus was developed by Bocsh in 1986 and it was first commercially used by Mercedes in 1992. It is multi master transmission, which broadcasts data all over the network with maximum transmission data rate of 1 Mbps.

CAN bus protocol is a multipoint communications system that connects different systems without the need of a master and a broadcast messaging system. CAN bus protocol receive data from different nodes simultaneously and the controller processes the data on priority bases. This guarantees fast data transmission


Electronic Control Units Keeps the vehicle's brain sharp and Intelligent.

Following are the features of Engine control unit.

Engine control units are linked and interact to control functions such as spark plug ignition timing, engine temperature, etc.

ECU can be removed from the unit to reprogram it according to the conditions to make the engine efficient or to altered it to fulfill the timely requirements.

ECU controls the air fuel mixture smartly to improve the fuel consumption.

CAN is an industry standard protocol used in automotive electronics and many new embedded environments where discrete components need sharing of information.CAN was initially developed for use in cars, to provide a cost-effective communications bus for in-car electronics and as substitute to expensive, unreliable wiring looms and connectors

CAN additionally feature:

Small message frame sizes (maximum of 8 data bytes) that guarantee access to the Network in short time periods.

Multi-master transmissions and collision avoidance determined through priority.

The physical layer requires one or two twisted pairs and is opposing to electrical


Network speeds up to 1Mbit that can be easily deployed in 8-bit microcontrollers.

The CAN BUS was developed by Bosch in 1986 as a multi-master message broadcast system that specifies a highest signaling rate of 1 megabit per second. Unlike traditional networks such as USB or Ethernet, CAN does not send large blocks of data from point-A to point-B under the supervision of a central master . In a CAN network, many short messages like temperature or speed are broadcast over the entire network. The short message format provides data consistency among all the nodes on the network.

In 1992, CiA(CAN in Automation) organized several chipmakers to standardize CAN, and one year later, the first CAN standard, ISO 11519, commonly referred to as low speed CAN, emerged with an 11-bit identifier and is used in applications up to 125 kbps. The second version, ISO 11898, was released in 1993, used an 11-bit identifier and offered data rates up to 1 Mbps. It is sometimes called CAN 2.0-A. An amendment was made in 1995 extending the 11-bit identifier to 29 bits known as CAN 2.0-B. Since 1992, CiA has worked with numerous industry groups to create Higher Layer Protocols (HLPs) that provide CAN network solutions apposite to industry requirements.

Working of ECU

Control of fuel mixture

An engine control unit (ECU) can determine the quantity of fuel to be injected on the bases of the following parameters. ass the throttle pedal is pressed, the throttle body opens, thus allowing air to enter the engine, the more the throttle will be pressed the more will the body open, allowing greater flow of air into the chamber. The ECU will analyse how much air is passing into the engine and inject the fuel accordingly.

Control of ignition timing

In order to initiate combustion in the chamber, a spark is required. The exact timing of the spark is critical to provide maximum efficiency and economy, this timing can be controlled by the ECU. If the knock (a condition which is potentially destructive to engines, that mostly result of poor ignition timing.) is detected, to prevent this the ECU delays (retard) the spark timing.

Another, more common cause, of knock/ping is when the engine is operated in low RPM range for certain timely requirements. As a result of this the piston is unable to move as fast as the flame expands ultimately producing a knock, to cope with such situation, the ECU simply downshifts the transmission.

Idle speed Control

Engine systems nowadays have idle speed control which is integrated into the ECU. In this speed control system, the engine RPM is first monitored by the position sensor on the crankshaft. As the function of crankshaft is directly related to rate of valve openings, the combustion within the cylinders and fuel injection amount and frequency, monitoring the function of crankshaft can give a fairly accurate idea of how the engine system is behaving. The idle speed of engine is then varied or controlled by either a programmable throttle stop or an idle air bypass control stepper motor; both of which essentially modify the combustion process within the cylinders and monitor the effect through the RPM measured at the crankshaft Early carburettor systems used a programmable throttle stop using a two way DC motor. However, the TBI systems used an idle air control stepper motor. An effective idle speed control must anticipate the system load when idle. This means that it has to account for any changes in the load due to changed use of powered vehicle systems (power brakes, power steering as well as electric charging and supply especially in hybrid vehicles). The engine temperature and transmission status as well as the magnitude and duration of the lift of camshaft also may change the engine load and hence the optimum idle speed value.

To further enhance the idea, a full throttle control may give the options to not only control idle speed but manage cruise control as well as top speed limitation functions.

Control of variable valve timing

Some car engines have Variable Valve Timing ,to optimize the air flow into the cylinder, this timing gets smaller at high speed and increases at low speed, to increase power and economy of the engine, the ECU can control the time in the engine cycle at which these valves open.

Electronic valve control

Experimental engines have been made and tested that have no camshaft, but has full electronic control of the intake and exhaust valve opening, valve closing and area of the valve opening. Such engines can be started and run without a starter motor for certain multi-cylinder engines equipped with precision timed electronic ignition and fuel injection. Such a static-start engine would provide the efficiency and pollution-reduction improvements of a mild hybrid-electric drive, but without the expense and complexity of an oversized starter motor.

Programmable ECUs

Some ECUs do not follow a fixed behaviour, they can be reprogrammed according to the timely requirements of the user. This makes the ECUs more flexible as the can be enhanced at any time.

Programmable ECUs come into play where a vehicle's engine need modification. It can be of any type, eg. changing turbocharger, intercooler, exhaust system, or modifications to run the engine on alternative fuel. With these changes in the engine's configuration the existing ECU may not be able to work properly. In Such situations, a programmable ECU is the best option which can be re-programmed with a PC connected to the ECU via a serial or USB cable.

As we have discussed earlier the ECU controls the fuel injection system,which is dependant upon two factors: The RPM of the engine or the throttle pedal. The engine can be tuned by analysing on a grid, the RPM value and the throttle position at different varying positions and in the cells the number corresponding to the amount of fuel to be injected is entered. This spread sheet is often referred to as a fuel table or fuel map.

Changing these values the tuner can monitor the exhausts to see if the engine runs rich or lean, this way the optimal amount of fuel to be injected to the engine can be found at all the different positions and RPM values of the engine.

Other parameters that can be monitored and modified are:

Ignition: Defines when the spark plug should fire for a cylinder.

Rev. limit: Defines the maximum RPM that the engine is allowed to reach. After this fuel and/or ignition is cut. Some vehicles have a "soft" cut-off before the "hard" cut-off.

Water temperature correction: Allows for additional fuel to be added when the engine is cold (choke) or dangerously hot.

Transient fueling: Tells the ECU to add a specific amount of fuel when throttle is applied. The term is "acceleration enrichment"

Low fuel pressure modifier: Tells the ECU to increase the injector fire time to compensate for a loss of fuel pressure.

Closed loop lambda: Lets the ECU monitor a permanently installed lambda probe and modify the fueling to achieve stoichiometric (ideal) combustion. On traditional petrol powered vehicles this air:fuel ratio is 14.7:1.

Some of the more advanced race ECUs include functionality such as launch control, limiting the power of the engine in first gear to avoid burnouts. Other examples of advanced functions are:

Wastegate control: Sets up the behavior of a turbocharger's wastegate, controlling boost.

Banked injection: Sets up the behavior of double injectors per cylinder, used to get a finer fuel injectioncontrol and atomization over a wide RPM range.

Variable cam timing: Tells the ECU how to control variable intake and exhaust cams.

Gear control: Tells the ECU to cut ignition during (sequential gearbox) upshifts or blip the throttle during downshifts.

The ECU of the racing cars also have data logger in it, that records the data from all the sensors, this is very handy way to look for flaws in the engine. This data is then extracted and analyse later on to fix the problems in the engine which avoids future misfires or undesired behaviours during race.

RPM, speed and other basic engine data needs to be presented to the race driver, and for this purpose, the race ECU is connected to a "data stack", which is a simple dash board presents the driver with the current stats of the engine. The data stack and the ECU communicate using one of several proprietary protocols running over RS232 or the CAN bus. Our project works on the basis of this CAN bus Protocol.

Modern ECUs

Nowadays the Modern ECUs also have microprocessors which process the data from the sensors. It is a complete package of an electronic control unit that contains the hardware as well as the software.

The hardware part as employed by the name comprises of electronic components mostly embedded on a printed circuit board (PCB). A microcontroller chip is the most important hardware component of an ECU, on which the software program is stored. The software stored in the microcontroller chips, can be re-programmed according to our requirements by uploading the updated software code or replacing chips/microcontroller.

Sophisticated engine management systems receive inputs from other sources, and control other parts of the engine; for instance, some variable valve timing systems are electronically controlled, and turbo charger waste gates can also be managed. They also may communicate with transmission control units or directly interface electronically-controlled automatic transmissions, traction control systems, and the like. The Controller Area Network or CAN bus automotive network is often used to achieve communication between these devices.

Modern ECUs sometimes include features such as cruise control, transmission control, anti-skid brake control, and anti-theft control, etc.

General Motors' first ECUs had a small application of hybrid digital ECUs as a pilot program in 1979, but by 1980, all active programs were using microprocessor based systems. Due to the large ramp up of volume of ECUs that were produced to meet the US Clean Air Act requirements for 1981, only one ECU model could be built for the 1981 model year. The high volume ECU that was installed in GM vehicles from the first high volume year, 1981, onward was a modern microprocessor based system. GM moved rapidly to replace carburetor based systems to fuel injection type systems starting in 1980/1981 Cadillac engines, following in 1982 with the Pontiac 2.5L "GM Iron Duke engine" and the Corvette Chevrolet L83 "Cross-Fire" engine. In just a few years all GM carburetor based engines had been replaced by throttle body injection (TBI) or intake manifold injection systems of various types. In 1988 Delco Electronics, Subsidiary of GM Hughes Electronics, produced more than 28,000 ECUs per day, the world's largest producer of on-board digital control computers at the time.

Introduction to CAN

CAN is a serial bus protocol to connect individual systems and sensors as an substitute to conventional multi-wire looms. It allows automotive components to communicate on a single or dual-wire networked data bus up to 1Mbps.[3]

CAN protocols types:

There are basically two types of CAN protocols: 2.0A and 2.0B.

CAN 2.0A is the earlier standard with 11 bits of identifier, while CAN 2.0B is the new extended standard with 29 bits of identifier. 2.0B controllers are completely backward-compatible with 2.0A controllers and can receive and transmit messages in either format.

There are two types of 2.0A controllers. The first is capable of sending and receiving 2.0A messages only, and reception of a 2.0B message will flag an error. The second type of 2.0A controller (known as 2.0B passive) sends and receives 2.0A messages but will also acknowledge receipt of 2.0B messages and then ignore them.[4]

CAN Basic Features

CAN has the following properties[6]

Based on a bus topology

Prioritization of messages

Carrier-Sense Multiple-Access (CSMA) protocol

Error detection and signalling

Configuration flexibility

Multicast reception with time synchronization


Automatic retransmission of corrupted messages as soon as the bus is idle again

Distinction between temporary errors and permanent failures of nodes and autonomous switching off of defect nodes

CAN bus offers remote transmit request (RTR)

How CAN works

CAN bus is not addresses based but each message contains a unique identifier ,so data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any desired receiving node.

All nodes on the network receive the message and each performs an acceptance test on the identifier to check if the message is relevant to that particular node or not. If the message is relevant, it will be accepted and processed; otherwise it is rejected. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. When two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost.[1]

Depending on the operational speed devices are connected to the bus, as in a typical vehicle application usually more than one CAN bus and their operational speed is different. Slower devices, such as door control, climate control, and driver information modules, can be connected to a slow speed bus. Devices that require faster response, such as the ABS antilock braking system, the transmission control module, and the electronic throttle module, are connected to a faster CAN bus.[4]

fig 1.3

CAN logic states

The data on CAN bus is differential and can be in two states: dominant and recessive. Figure 1.4 shows the state of voltages on the bus. The bus defines a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit. When there is arbitration on the bus, a dominant bit state always wins out over a recessive bit state.

In the recessive state, the differential voltage CANH and CANL is less than the minimum threshold (i.e., less than0.5V receiver input and less than 1.5V transmitter output). In the dominant state, the differential voltage CANH and CANL is greater than the minimum threshold.[4]

CAN Versions:

The 1st version of the CAN standards, ISO 11519 (Low-Speed CAN) is for applications up to 125 kbps with a standard 11-bit identifier. The 2nd version, ISO 11898 (1993), also with 11-bit identifier offers signalling rates from 125 kbps to 1 Mbps and the more recent ISO 11898 amendment (1995) introduces the extended 29-bit identifier.

The ISO 11898 11-bit version is referred to as Standard CAN Version 2.0A and the ISO 11898 amendment is referred to as Extended CAN Version 2.0B. Also Standard CAN Version 2.0A is occasionally referred to as Basic CAN, and Extended CAN Version 2.0B is occasionally referred to as Full CAN.

The Standard CAN 11-bit identifier field in Figure 2 provides for 2^11 or 2048 different message identifiers, while the Extended CAN 29-bit identifier in Figure 3 provides for 2^29, or 537 million identifiers.

The Bit Fields of Standard CAN and Extended CAN:

Standard CAN

The meaning of the bit fields of Figure 2 are:

SOF-The single dominant start of frame (SOF) bit marks the start of a message, and is used to synchronize the nodes on a bus after being idle.

Identifier-The Standard CAN 11-bit identifier sets the priority of the message.

RTR-The single remote transmission request (RTR) bit is dominant when information is Required from another node. All nodes receive the request, but the identifier determines the desired node. The responding data is also received by all nodes and used by any nod interested. In this way all data being used in a system is uniform.

IDE-A dominant single identifier extension (IDE) bit means that a standard CAN identifier with no extension is being transmitted.

r0-Reserved bit (for possible use by future standard amendment).

DLC-The 4-bit data length code (DLC) contains the number of bytes of data being transmitted. Data-Up to 64 bits of application data may be transmitted.

CRC-The 16-bit cyclic redundancy check (CRC) contains the `checksum (number of bits transmitted) of the preceding application data for error detection.

ACK-Every node receiving an accurate message overwrites this recessive bit in the original message with a dominate bit, indicating an error-free message has been sent. Receiving node detects an error and leave this bit recessive, it discards the message and the sending node repeats the message after re-arbitration.

EOF-This end-of-frame (EOF) 7-bit field marks the end of a CAN frame (message) and disables bit-stuffing, indicating a stuffing error when dominant. When 5 bits of the same logic level occur in succession during normal operation, a bit of the opposite logic level is stuffed into the data.

IFS-This 7-bit inter-frame space (IFS) contains the amount of time required by the controller to move a correctly received frame to its proper position in a message buffer area.

Extended CAN:

As shown in Figure 3, the Extended CAN message is the same as the Standard message with the addition of:

SRR-The substitute remote request (SRR) bit replaces the RTR bit in the standard message location as a placeholder in the extended format.

IDE-A recessive bit in the identifier extension (IDE) indicates that there are more identifier bits to follow. The 18-bit extension follows IDE.

r1-Following the RTR and r0 bits, an additional reserve bit has been included ahead of the

DLC bit.[7]

Message Types

There are four different message types, or frames (Figures 2 and 3) that can be transmitted on a CAN BUS:

the data frame

the remote frame

the error frame

the overload frame

A message is considered to be error free when the last bit of the ending EOF field of a message is received in the error-free recessive state. A dominant bit in the EOF field causes the transmitter to repeat a transmission.

The Data Frame

The data frame is made up by the arbitration field, the CRC field, the acknowledgement field and the data field. The arbitration field tells the priority of a message when two or more nodes are struggling for the bus. The arbitration field consists of an 11-bit identifier for CAN 2.0A in Figure 2 and the RTR bit, which is dominant for data frames. For CAN 2.0B in Figure 3 it consist the 29-bit identifier and the RTR bit. The data field contains zero to eight bytes of data and the CRC field contains the 16-bit checksum used for error detection. At the end there is the acknowledgement field. Any CAN controller which is able to receive a message correctly, sends a dominant ACK bit that overwrites the transmitted recessive bit at the end of correct message transmission. The transmitter checks for the dominant ACK bit and retransmits the message if no acknowledge is detected.

The Remote Frame

The desired purpose of the remote frame is to obtain the transmission of data from another node. The remote frame is same as the data frame but with two important differences. First, this type of message is explicitly marked as a remote frame by a recessive RTR bit in the arbitration field. secondly there is no data.

The Error Frame

This frame is a special message that breaks the formatting rules of a CAN message. It is transmitted when a node finds an error in a message, and causes all other nodes in the network to send an error frame as well. The original transmitter then automatically retransmits the message. There is an careful system of error counters in the CAN controller which ensures that a node cannot tie up a bus by repeatedly transmitting error frames.

The Overload Frame

The frame is similar to the error frame with regard to the format, and it is transmitted by a node that becomes too busy. It is basically used to provide for an extra delay between messages.[7]

Error Checking and Fault Confinement

The CAN protocol implements five methods of error checking: three at the message level and two at the bit level.

The CRC and the ACK slots are at the message level as displayed in Figures 2 and 3. The CRC which is 16-bit contains the checksum of the preceding application data for error detection with a 15-bit checksum and 1-bit delimiter. The 2-bit ACK field consists of the acknowledge bit and an acknowledge delimiter bit. The form check is also at the message level. It looks for fields in the message which must always be recessive bits. If a dominant bit is detected, an error is generated. The SOF, EOF, ACK delimiter, and the CRC delimiter are the checked bits.

At the bit level the transmitter of the message is monitoring each transmitted bit. If a data bit (not arbitration bit) is written onto the bus and its opposite is read, an error is generated. The message identifier field which is used for arbitration, and the acknowledge slot which requires a recessive bit to be overwritten by a dominant bit are the only exceptions to this. The bit stuffing rule is the final method of error detection where after five consecutive bits of the same logic level if the next bit is not a compliment then an error is generated. it ensures rising edges available for on-going synchronization of the network, and that a stream of recessive bits are not mistaken for an error frame, or the seven-bit interface space that signifies the end of a message. Stuffed bits are removed by a receiving node's controller before the data is forwarded to the application.[7]

Error Frame

With any one of these error detection methods if a message fails then it is not accepted and an error frame is generated from the receiving nodes causing the transmitting node to resend the message until it is received correctly. But if a faulty node hangs up a bus by continuously repeating an error, its transmit capability is removed by its controller after an error limit is reached.[1]

MikroC Functions Overview

There are number of compilers but We have used the MikroC.

The following are the mikroC functions which we have use in our project:


The Prototype of the function is

Void CANSetOperationMode(unsigned short mode, unsigned short wait_flag);

It sets CAN to requested operation mode, i.e. copies mode to CANSTAT. The parameter wait_ flag is either 0 or 0 x FF. If it is set to 0 xFF this is a blocking call and will not return until the requested mode is set. If it is set to 0, the function returns as a no blocking call. The mode can be one of the following:

CAN_MODE_NORMAL Normal mode of operation

CAN_MODE_SLEEP Sleep mode of operation

CAN_MODE_LOOP Loop-back mode of operation

CAN_MODE_LISTEN Listen-only mode of operation

CAN_MODE_CONFIG Configuration mode of operation


The prototype of the function is

Void CANInitialize(unsigned short SJW, unsigned short BRP, unsigned short PHSEG1, unsigned short PHSEG2, unsigned short PROPSEG, unsigned short CAN_CONFIG_FLAGS);

where parameters are

SJW is the synchronization jump width

BRP is the baud rate prescaler

PHSEG1 is the Phase_Seg1 timing parameter

PHSEG2 is the Phase_Seg2 timing parameter

PROPSEG is the Prop_Seg

We have us used the following configurations:







The prototype of the function is

void CANSetMask(unsigned short CAN_MASK, long value, unsigned short CAN_CONFIG_FLAGS);

It sets mask for advanced filtering of messages. CAN_MASK can be one of the following:

CAN_MASK_B1 Receive buffer 1 mask value

CAN_MASK_B2 Receive buffer 2 mask value

value is the mask register value. CAN_CONFIG_FLAGS can be either

CAN_CONFIG_XTD (extended message),or

CAN_CONFIG_STD (standard message).


The prototype of the function is

Void CANSetFilter(unsigned short CAN_FILTER, long value, unsigned short CAN_CONFIG_FLAGS);

It sets message filter.

We have used the following modes

CAN_FILTER_B2_F3 Filter 3 for buffer 2

CAN_FILTER_B1_F1 Filter 1 for buffer 1

CAN must be in Config mode; otherwise the function will be ignored.


The prototype of the function is

Unsigned short CANRead (long *id, unsigned short *data, unsigned short *datalen, unsigned short *CAN_RX_MSG_FLAGS);

It reads message from receive buffer. If at least one full receive buffer is found, it is extracted and returned. If none found, function returns zero.

The Parameters are:

id is message identifier

data is an array of bytes up to 8 bytes in length

datalen is data length, from 1-8.

CAN_RX_MSG_FLAGS is value formed from constants


The prototype of the function is

unsigned short CANWrite(long id, unsigned short *data, unsigned short data len, unsigned short CAN_TX_MSG_FLAGS);

If at least one empty transmit buffer is found, function sends message on queue for transmission. If buffer is full, function returns 0 and CAN must be in Normal mode.

Requirements Specification

Non-functional Requirements

Product requirements






Platform: window operating system









Microcontroller: PIC18F4580






Machine: personal computer or Laptop & PIC kit

Organisational requirements






Delivery: The system development process and deliverable documents shall conform to the process and deliverables defined in the document "project proposal report" and " project progress report"



Standard: The standard of the final product shall be of undergraduate level

External requirements






Security: This is a degree project having no strict security requirements.



Ethical: The application will not use any type of un-ethical electronic material while project development and execution.



Legislative: The application shall not use any private or confidential data, or network information that may infringe copyrights and/or confidentiality of any personnel not directly involved in this product.

Functional Requirements

We are providing the functional requirements which are as following


Temperature Node

Speed Node

Mass-air flow node

Display Node


Mikro C


The hardware of the "Design of engine control unit" provides the circuitry for collecting the data from 3 different parameters of car engine, and their communication using CAN protocol to the Central node where it is processed and displayed on an LCD. This explains that hardware is based on four nodes: Temperature Node

The temperature node uses the LM35 temperature sensor (digital) to measure the temperature this node has PIC 18F4580,which has been programmed to receive data from sensor and transmit it over to the display node for processing and display to the user using the can transceiver MCP2551. Speed Node

The speed node measures the speed using the U-shaped sensor (opto-coupler). This node also has PIC 18F4580,which has been programmed to receive data from sensor and transmit it over to the display node for processing and display to the user using the can transceiver MCP2551.

Mass-air flow node:

The mass air flow sensor sends it digital data to the PIC18F4580 which transmits it to the central node using CAN transceiver MCP2551. Display Node

Display node shows the value of other two nodes (temperature &speed) which are interface with it. This node has a PIC18F4580 and 16*2 LCD.


The software of the "Design of Engine control unit "is intended to generate the successful programs which support the hardware design in the best possible way. The three sensing nodes are programmed to transmit their data over CAN bus and the Central node is programmed to process and display that data on the LCD. Mikro c

We choose mikroC language because mikroC provides a library (driver) for working with CAN module.

Appendix D: Project Timeline



















* You can provide Gantt chart instead of filling this form, if you like