The project where I spend most of my time right now is Chalmers formula student where I am Project engineer in the Vehicle electronics subgroup. This post is a summary of the design of the over-all wiring. If I find the time I will also post some more information about other subsystems.

2.1.Technical Background

The overall wiring provides electrical power to the components and transfers signal data from sensors to the processing nodes. The overall schematics refer to the design of this electrical system. The schematics are necessary when connecting the electrical system on the car. It is also very useful for troubleshooting and repair of the system.

2.2.The over-all wiring

2.2.1.Design choice/ selection

Our target goals are presented in the table below:

2.2.1.1.Schematics

The approach when designing the over-all wiring was to start with a low complexity model where the most important subsystems were represented. Understanding the interactions between subsystems is important to get efficient and minimal wiring and therefore the solution model is a good starting point. Designing the vehicle schematics is an iterative process where information is added for most of the new design decisions. The schematics include component specification, choice of connector, pin configurations, connections to the processing nodes, sensors, engine control unit with wiring, generator, fuel pump and power supply.

2.2.2.Packaging of circuit boards, connectors and cables

Protection level IP45 is chosen from pre-study to get sufficient protection from water, dirt and dust. Our assumption when choosing the protection level was that water is a bigger issue than dust since water implies a greater risk for electric failure. IP45 will give protection from dust and dirt above 1mm and protection from ingress of water from a water jet. Going for IP65 increases the protection to be completely protected from dust and protection from water up to more powerful water yet.¹ Upgrading the protection level to IP65 to get a safety factor was not too difficult since boxes from Multicomp together with Buccaneer connectors satisfy this specification.

To avoid disturbances cables carrying signals are separated from cables carrying high currents and shielded cables are used in high disturbance zones near the engine.

Connectors for sensors have to have a high water and dust protection level since they will be unprotected by any other component. To get a low maintenance time when dismounting a subsystem from the electronics they have to be easy to connect and disconnect. They should also not be too expensive. TE connectivity Superseal 1.5 series (Figure ) with IP67 will meet this requirement.²

Figure : TE Connectivity Superseal 1.5 Series³

Connectors for the processing nodes was set to have the same requirements as for the sensor connectors but with a constraint that the female connector has to be mounted at the side of the box containing the processing nodes. Circular connectors were chosen since they make the manufacturing of the processing nodes easier compared to using rectangular connectors. It is also much easier to find circular connectors with sufficient water and dust protection. Buccaneer 400 series (Figure ) which have IP68 classification are chosen.

Figure : Buccaneer 400 series⁴

A hole on each side in the monocoque is used for wiring the sensors near the front wheels to the front processing node. Delron Inserts 102 series (thru-bolt) will be inserted into the hole for water and dust protection.

2.2.3.Discussion of design selection/ Limitations

Alternative solutions for the overall wiring were discussed and benchmarked. The main reasons for rejected design alternatives were reduced reliability or increased complexity.

2.2.3.1.Alternative connection between sensors and inside monocoque

Instead of drilling a hole at each side of the monocoque to transfer a cable for the sensors at the wheels a connector could have been used. We had discussions about using connectors from Deutsch which would be lightweight and robust. The main disadvantage was the wiring inside the monocoque. With a connector the bend of the wires connected to the connector must not get in the way of the driver’s legs. The driver department should be as clean as possible to avoid the driver hitting any protruding parts. Adding a connector would increase this risk and therefore the solution was rejected.

2.2.3.2.Two nodes and the alternatives

The reason for choosing a two node system was to reduce wiring and divide logging and processing on two processors. A two node system with a CAN bus is much easier to expand than a single node system. Adding more sensors can be done by connecting them to free inputs on either of the two nodes or by adding a new node since a CAN bus is used. One design alternative that was considered was to have small nodes by each wheel with a CAN bus connecting them. This could decrease wiring even further since the distance from each sensor to a close by node would be smaller. The main reason for not choosing this design was to limit the number of developed components. Our recommendation though to next year’s CFS would be to consider this approach.

2.2.3.3.Alternative connection of the ECU

An alternative to the current solution of connecting the ECU to the rear node via RS232 would be to connect it to the CAN bus⁵. Since the rear node in this case would not need to handle the communication to the ECU and instead get the data from the already implemented CAN bus communication the processing would be reduced. The same would be true reducing the programming code when using CAN instead of RS232 since the CAN code has to be implemented either way. The disadvantages are added components since the ECU does not have a CAN interface but a RS232 interface. A purchase of a CAN adapter would be needed with increased cost as result. The programming code for communication to the ECU was implemented last year and will hopefully reduce the development time this year which makes the advantages of the CAN interface less important.

2.2.3.4.Alternative 1 for connecting the DASH3

Using a serial adapter between the DASH3 and the DAQ would make the dashboard able to read sensor values from the data logger. This solution was most importantly not chosen since it would increase the number of components and the complexity of writing to the dashboard did not seem too great to overcome since the dashboard protocol is open⁶. Even though Race Technology in an email wrote that the logging capacity would not be decreased by much since the update frequency to the dashboard does not have to be more than a couple of times per second, we were not sure if it would be a limiting factor or not. The safe option was to not use the serial adapter and instead send the data from the front node. The disadvantage of this solution is more development time since routines needs to be programmed for communication between the node and the dashboard. With the serial adapter this is already done by Race Technology.

2.2.3.5.Alternative 2 for connecting the DASH3

Connecting the DASH3 to the CAN bus would be done with a CAN adapter. The distance from the DASH3 to the front node is so close that any weight saving due to wiring would not be a factor. The main advantage would be an assumed reduced development time since the sensor data to display on the dashboard would already be present on the CAN bus. Only configuration of the DASH3 would be necessary.

2.2.3.6.Alternatives to the circular connectors in the processing nodes

An alternative to the circular connectors in the processing nodes would be rectangular connectors. If the processing nodes are better protected from water and dust this would be a good option since it makes connecting sensors somewhat easier. A disadvantage with circular connectors is that they require soldering or the use of clamp tool. Adding sensors to a rectangular terminal block would be a matter of just connecting wires to the connector block. This connector is for example used on the DAQ (Figure ) which we use for data logging.

Figure : Race Technology DL1 MK3 DAQ

2.2.3.7.Alternative driver interaction design by combining switches

To minimize the amount of switches on the dashboard it is possible to combine the switches for ignition, fuel pump and start engine into a switch with multiple states; Off, Ignition, ignition+fuel pump and start engine (with momentary action). The main disadvantage is lost control of forcing the fuel pump to be either on or off. The states of this switch would be:

1. Off

2. Ignition

3. Ignition and fuel pump

4. Starter motor. This state would be momentary stable and return to state 3 when released.

The reason this solution was neglected was loss of control of the fuel pump. With a dedicated switch for fuel pump three states can be selected:

1. No fuel pump

2. Fuel pump controlled by ECU

3. Fuel pump forced on

2.2.4.Simulations/ Tests/ Experiments

The first approach for the schematic design was to do it by hand on paper (Figure ) and then convert this to 2D CAD software. For developing the vehicle schematics a comparison between alternative software was done. A brief summary of the software comparison test:

1. ExpressSCH seemed quite good at first but adding components was a hassle.

2. FastEl did simple tasks complex and lacked user friendliness.

3. Eagle CAD has two main features: board design and schematics design. Designed for manufacturing PCBs and therefore a lot of features would be left unused when only designing schematics

4. TinyCAD is a simple and fast program without any advanced features.

TinyCAD was chosen since it got the job done and was fast to work with compared to the other alternatives.

Figure : Iteration 2 of schematics on paper

2.2.5.Over-all schematics

Click on the image and then download it as a png. The schematics file is very big and the image below is just a thumbnail.

Direct link to schematics image