CHAPTER 6: IMPLEMENTATION
6.1 STEPS INVOLVED IN DESIGNING AN INSTRUMENT CLUSTER
6.1.1 REQUIREMENT ANALYSIS
The motive of this project implementation is to design and implement a cluster as per the requirements given by the customers (OEMs). Hence, the first step in designing a cluster is requirement gathering.
In this step, the cluster design is gathered from the OEMs. Different OEMs have their own design specified. The designs vary in wide varieties especially in the position of the components (Speedometer, indicator, warnings etc.) on the instrument cluster. Also, the designs take into considerations the driver comfort and safety and thus, many designs with different variants ranging from low to high is proposed.
As discussed earlier, the technology advancements expect the traditional mechanical and electronic clusters with fixed displays to be replaced by clusters more dynamic and flexible. This is because the traditional clusters, involve more hardware like the gauges, LEDs etc., which are static in their position. This restricts the amount of information that can be displayed on the cluster.
Also, when more systems are introduced, it is necessary that the cluster just displays what the driver needs at the current situation, rather than displaying all the information.
Hence, this project concentrates on a fully digital and freely programmable cluster design. The need for such a cluster is illustrated in figure 6.1 and 6.2.
Fig 6.1. Instrument cluster under normal scenario.
Fig 6.2 Dynamic instrument cluster implementation.
As seen in the above figures, An element occupying larger size has to be displayed . But, at the same time speed value has to be displayed. Hence, both the dials are pushed to the side in a way visible to the driver. This can be achieved only by a dynamic instrument cluster.
When the cluster is fully digital, it becomes easier for dynamic display. A freely programmable cluster makes it easier to modify and upgrade an already designed cluster to different variants.
The OEMs gives these inputs as photo. With that photo as reference, the exact cluster is designed, with exactly all the components in their exact position specified.
6.1.2 SYSTEM ANALYSIS
After gathering the photo of the cluster design, the design is completely analysed. Each component functionality is studied. In this the project, the main aim is implementing speedometer, tachometer, indicator and fuel bar. Thus, functionality of each is studied to implement the same in the cluster. Here,
Speedometer – This is used to indicate the current speed of the vehicle.
Tachometer –This is used to indicate the Revolutions per Minute (RPM) of the wheel.
Indicators – These are used to indicate the direction of turn of the car. Also, they can be used as warning to indicate that the car is moving slow, and in some cases they can be used when it is too foggy and misty. In these cases, both the indicators are turned on.
Fuel bar – This is used to indicate the amount of fuel in the fuel tank.
The functionality study is done to understand how the element has to be implemented on the display. A thorough system study and thus the functionality study is needed for better implementation of the design.
In addition, the resources required to design the scene is analysed. The main aim is to design an innovative cluster with minimum resources.
6.1.3 MODULE DESIGN
After analyzing the photo of the cluster, it is exported to the scene-designing tool. Each component of the cluster such as the speedometer, tachometer etc. are designed as separate scenes in this scene-designing tool.
In the scene-designing tool, the photo of the required cluster is imported. In this process, every component is imported with exactly the same position and size as required by the customer.
Then, each component of the cluster is exported inside the scene-designing tool as separate scenes. By doing so, the each component is separated, retaining its position and size. Now, each scene is designed separately. After all the scenes are designed, assets are generated which integrates the separately designed scene on a common display.
In the given graphics, the speedometer designed is as shown in figure 6.3.
The speedometer forms the left dial of the given cluster graphics.
As seen in figure, the speedometer represents speed using both analog dials and digital speed. In contrast to the mechanical analogue gauges used to represent the analogue speed, the entire graphics is a digital display. Hence, each component in the speedometer which includes,
Each of the above, are imported as separate components in the scene. These components are either bitmap images or text and are referred to as a node. In this scene except the digital speed value, all others are bitmap nodes. In this scene-designing tool, each bitmaps placed in the exact positions as required. The bitmap is bounded by a rectangle with a pivot point. This point is the point of reference for any transformation like scaling or rotating done to the bitmap. For e.g. the needle’s pivot point has to positioned such that it rotates accurately to indicate the analogue speed.
Note that in figure 6.3, the dial is closer than analogue speed values. Similarly each bitmap node or text node in the scene are arranged in different layers. Some may be close and some may be farther from the screen. The parameter that differentiates this layers is called as the depth value. Comparing with the photo given by the customer, the depth value is calculated and assigned accordingly to each node.
Thus, each node in this scene is positioned and arranged. The static scene is thus designed successfully.
After designing the static design, the functionality has to added or in other words, dynamicity has to be added to the scene. The entity that adds dynamicity is called the widget. The scene-designing tool has offers different widgets to implement different functionalities like:
Transformation – for rotating and scaling
Tube – for rotating
Text Effect- to display a text
Telltale – to indicate a warning
In the tool, each node in the scene is associated with the respective widget to implement the scene. Here, for instance the needle is associated with a tube widget.
Similar to speedometer , other scenes are implemented.
The design of tachometer is similar to the speedometer as it has the same components as the speedometer. The tachometer in the given graphics is the right dial. The tachometer designed is as shown in figure 6.4.
Fig 6.4 Tachometer
The tachometer is similar to the speedometer and it also has needle, dial, analogue RPM dial etc. As discussed in the speedometer scene, the tachometer is first designed statically and then widgets are added to the nodes to add dynamicity.
The indicators implemented in the cluster are as shown in figure 6.5.
Fig 6.5 Indicators
In contrast to the other two scene, here there is no rotation involved. The indicators have to blink according to the input key. Hence, here telltale widgts are added to the two bitmap nodes i.e., the left and right arrow.
The fuel bar implemented in the cluster graphics is as shown in figure 6.6.
Fig 6.6 Fuel Bar
Here, the fuel level has to increase or decrease according to the level of fuel in the tank. Since it is a linear movement, a bar graph widget is used.
Hence, in the scene-designing tool, each scene is positioned statically and the widgets are assigned to the respective nodes. It is important to note that, till this point, the nodes are just associated to the widgets. For instance, the needle of the dials is assigned to the tube widget because its function is to rotate. But, how much the needle has to rotate, when it has to rotate is not yet configured. That is, the cluster has to become functional. The cluster has to take inputs and react accordingly. This is achieved through codes.
After the cluster is designed using the scene-designing tool, its functionality has to be implemented. After successful implementation, it has to be verified in the PC. On successful verification, it is flashed on to the target and tested in the target, after which it is delivered to the customer.The implementation of cluster is through coding. As discussed in the previous chapter, the clusters are implemented using the MVC architecture. The MVC architecture is achieved by implementing using a framework. The framework has interfaces and classes which can be derived and modified to implement the desired functionality.
As discussed before, the interaction between the three components is asynchronous and hence through messages. Hence, the data received through the interface is encapsulated to a message. How the module designed in the scene-designing tool is implemented is discussed below.
First, each scene’s path is mapped to an ID, to interface the scene designed in the tool to the code. After mapping all the scenes, the view part of the entire scene is designed. It is already known that the view part is responsible for the graphical display. That is, it is this component that decides how that data has to be displayed.
Inside every view part, there is a controller called view controllers. These are the main part of the view component whose primary role is to initiate the widgets. These view controllers are nothing but simple cpp codes, written to receive the data from the model and initiates the widgets to display the value accordingly. That is, when a tube widget has to rotate and the value to which it has to rotate is given to the widgets through the view controllers.
In the cluster design for instance, speed view controllers are written to render the speedometer scene. Inside this view controller, functions are defined to receive the speed value from the model. The value is then initialized to the pointer to the tube widget. Then the widget rotates to indicate the value received.
Thus to summarize:
A cluster is designed using a scene-designing tool after the requirement and system analysis is done. The cluster designed is non functionality. The functionality is added by writing the view controller codes. It is important to understand at this point that, controller activates or deactivates the scene. And, only when the view controllers are created the scene is rendered and can receive messages.
The cluster is thus successfully implemented using the MVC architecture.
6.1.5 TESTING AND FLASHING
The designed cluster has to be tested to verify its functionality. The instrument cluster designed in the PC is not in an automotive environment. There is no ECUs, CAN networks and any system. But the designed scene has to be tested for its optimized implementation. Testing the design in PC reduces the cost of testing directly in the car. So, it is necessary to virtually create a system or a processor that posts its input to the model component in the architecture.
To mock such a system, the inputs or rather the keys from the keyboard are used as acquired input signals in the original implementation. For instance, the key ‘A’ from the keyboard can be treated as the input speed value and so on. Codes are written to receive this value as the acquired speed value and are sent to the model component. The model component then encapsulates this value which is of primitive data type and posts it to the message queue, from which the view and controller part receive the data if they need. Thus the functionality of the designed cluster can be tested using the PC.
Then asset or the binary files are generated and flashed to the target hardware and further tested on the target hardware.
The target hardware is just the cluster hardware alone. That is, it is not connected to car. Thus a simulator is used to generate the necessary CAN signals and verify the functionality of the cluster.
The implementation steps involved can be represented in a flow chart as shown in figure 6.7:
Fig 6.7 Flow chart for the cluster implementation
The next chapter briefly describes the design challenges faced during the project implementation.