Activity Duration Start Finish 1 Receiving the license theme 1 day 6.07.2020 6.07.2020 2 Finding the theoretical documentation 20 days 6.07.2020… [626737]

2. Activity planning
Activity Duration Start Finish
1 Receiving the license theme 1 day 6.07.2020 6.07.2020
2 Finding the theoretical documentation 20 days 6.07.2020 25.07 .2020
3 Studying , choosing and writing the
necessary documentation 6 days 26.07 .2020 31.07 .2020
4 Implementation of the simulated
inteface 10 days 01.08.2020 10.08.2020
5 Implementation of code 17 days 10.08.2020 26.08.2020
6 Testing the application 4 days 27.08.2020 30.08.2020
7 Implementation of the final
documentation 4 days 28.08. 2020 31.08.2020

3. Current stage
3.1 Beginnings in automotive field
The history of the automobile begins in 1769, with the creation of the car. In 1806, vehicles
with internal combustion engines using liquid fuel appeared. Around 1900, e lectric vehicles also
appeared. The car is rapidly gaining ground in developed countries as the main means of transport.
The car industry registers a good period , especially after World War II. If at the beginning of the
twentieth century there were severa l hundred thousand, at the beginning of the postwar period there
were more than 500,000 cars worldwide, so that in 2007 the annual world production exceeded 70
million.
In 1828, the hungarian Ányos Jedlik realised a primitive model of electric motor and wi th this
an electric powered vehicle. In 1834, the American blacksmith Thomas Davenport, the inventor of the
DC motor, made a vehicle propelled by this motor that moved on a circular guide equipped with
electric power conductors.
In 1899, the Belgian Camille Jenatzy exceeded 100 km / h with an electric vehicle called Jamais
Contente. Around 1870, the austrian inventor Siegfried Marcus made the first gasoline -powered
vehicle. The first truly efficient modern gasoline engines was made by Karl Benz, a pat ented invention
on January 29, 1886, which he used in a three -wheeled car. In 1885, Gottlieb Daimler built an internal
combustion engine, which used gasoline as fuel, and the following year, together with Wilhelm
Maybach, designed a car that no longer rese mbled a horse -drawn vehicle equipped with such an
engine. In 1891, cars made by Panhard and Levassor, equipped with a Benz engine, began to run
through Paris. The first Peugeot horse -free cars were sold under the Panhard & Levassor name.
The first mass production of automobiles was initiated by Karl Benz in 1888 in Germany.
Around 1900, mass production of automobiles was introduced in France and the USA. The first
company wich was exclusively responasble of this field was Panhard et Levassor, founded in 1889
and whose notable achievement was the introduction of the four -stroke engine on a vehicle that could
carry four people. Two years later, the famous Peugeot appeared.
3.3 Why is software testing important?
Of course, we can put ourselves this question : Why is testing important? Why is so important
in the process of developing a software product, when in the vast majority of cases, the merit of testers
is not as much appreciated as that of developers. Well, the the answer is extremely simple: testing is
necessary because we all make mistakes. Maybe some of those mistakes are not so important, but some
of them are very expensive and really dangerous. It is extremely important to check the product so that
it can be validated, human error being an extremely common factor which can cause considerable
damage in the development process. By testing our own work, the chances of finding errors are quite
small, which is why we should have someone else check our work, in this way, having more chances
to detect defe cts.
There are many reasons which attest the importance of testing, some of this reasons are:
– Software testing is necessary to highlight defects and errors that have been made in the
development phases, because programmers can make mistakes during software
implementation due to lack of experience, incorrect implementation of the algorithm or
simply human error.

– Some customer contracts may also include monetary penalties for the timing and quality of
the product. In this case, if we have an effective testing plan, such losses can be avoided. It
is vital to ensure product quality, a quality product delivered to customers helping to
increase confidence in the final results of the product and thus customer satisfaction
increase. Also, timely product deliv ery is an extremely important aspect.
– The product delivered in compliance with a test plan has fewer defects and requires less
maintenance effort, which in turn means low costs, again an important aspect for the
customer. If defects related to requirements or late design are detected, it can be very
expensive to fix them because this may require redesigning, re -implementing and re –
analyzing the application.
– Users will not want to use buggy software, because this decreases the stability of the
application.
3.3 Automotive testing : the automotive tester profile
The role of the tester in the automotive field involves a number of responsibilities, including:
security testing, this includes knowledge and implementation of specific security standards, for
example I SO26262, creation of manual tests and automatic scripts, a very important role here have the
tests of performance and "loading", a very good knowledge of test methodologies, programming s kills
and also business skills.
For the automotive field, it is crucial to know the business and implicitly the risk and impact
that any undetected error in the code can have. If for an educational game software engineer the risks
are copying or reproducing the software, in the financial field we are talking about very large material
losses, in automotive we are talking about both material losses and human lives, which means
dentifying and empowering testers in this regard is essential. The skills and abilities necessary for the
automotive tester do not stop here. The l ist continues with attention to detail, analytical technical
thinking, risk analysis skills, gathering and interpreting information according to required standards,
planning, monitoring and organizing operations and activities, customer orientation and und erstanding
the risks of ignoring this, and skills organization and good communication.

3.4 Overview of the future in automotive
A particularly important aspect in the automotive industry are the future prospects that this
field offers , reason for which , this subchapter is intended to present the new trends in this area of
activity. Aspects such as autonomous driving, connectivity, electrification, and ridesharing which are
leading us to a new world in the automotive universe. Starting from the initials of the four trends, the
term ACES is discussed . The last one, autonomous really is what it is call from level one to level five,
with level five being a driverless car that can operate in any part of the world. Connectivity is th inking
of the car as a computer on wheels. A car is going to have 200 million lines of software code in the
future, in comparison with Facebook which has 50 million lines of code. Electrification is the shift
from the bedrock of the industry, which has b een the internal -combustion engine to a whole range of
battery applications.
Of course, all these changes will take time, but we will see the first signs of change relatively
quickly, currently there are companies working to bring out the first set and th e first fleet of robot cars.
But in certain types of cities and in certain short periods of the day it will be possible to experience
autonomous driving. An example would be the first autonomous bus in Germany, put into operation
in a small town for a dist ance of a quarter of a mile. It is an anticipate fact that these changes will have
a huge impact in the future, both on the profit fund and on the income group of the industry. Actually ,
we can say that connectivity it’s already here, most consumers are pa ying attention to the kind of

software enablement that cars provide and many of the carmakers completely rethought the customer
experience and the customer interface.
It is extremely important to start from the checkpoints in the ecosystem, these are the most
important elements for the customer. The elements of the value proposition for the customer are what
matter. Another important aspect that car companies should do is monetize data, for example, usage –
based insurance. The third aspect is based on the i dea that as the car becomes a computer on wheels,
the amount of software content in the car will triple in the coming years, which is why a massive
increase in the number of software engineers will be needed. For much higher productivity in software
develo pment, the model predicts that approximately 100,000 additional software engineers are needed
for the US auto industry alone, which is a considerable number and a major challenge.
The vast majority of consumers are looking for driver assistance systems tha t bring safety, and
one thing the car industry needs to ensure is to have a clear view of how the consumer uses the product
and what they need to do to improve the customer experience and to offer necessary satisfaction. The
term facilitation comes into qu estion, which is a certain level of integration of technology with other
actors in the ecosystem, so with the possibility of providing a positive impact on the customer
experience. The mode of cooperation will be completely different, being an open platform for several
companies that will present their skills, car players integrating them into a product and thus ensuring
that the customer experience is there. This brings a great challenge to companies, caused by a more
dynamic cooperation.
Knowing th at the industry invests considerable amounts in ensuring the maturity and quality
levels of a product by prototyping, by testing durability, as well as the machine in the future, with
monitoring conditions, constant views on the machine, many of these wil l be done through simulations,
by digitizing and by constantly presenting the condition of the car in drumm, ensuring quality for the
consumer, fact which will require much lower costs.
As a conclusion of this topic, it is interesting to follow the direction of the industry, because an
overview seems to bring us closer to a scientific -fictional future: we are talking about cars without
drivers, which can speak or drive without fossil fuels. All this things are fascinable scenarios, which
will be plau sible in a near future and which have been hard to imagine in the past. What is certain is
that technology is constantly evolving, surprising us with new and interesting research.

4. Theoretical substantiation
4.1 Software testing definition
In computer science, a test refers to a procedure of partial verification of a system. Its main
objective is to identify a maximum number of problematic software behaviors. As soon as the
identified problems are corrected, it makes it poss ible to increase their quality. More generally, the test
designates all activities that seek information about the quality of the system to enable decision –
making. A test is like a scientific experiment. It examines a hypothesis expressed in terms of three
elements: the input data, the object to be tested and the expected observations. This review is carried
out under controlled conditions so that conclusions can be drawn and, ideally, reproduced.
A test is a set of cases to be tested (the condition of the o bject to be tested before running the
test, actions or input data, expected values or observations and the condition of the object after
execution), possibly accompanied by an execution procedure and related to an objective. Therefore,
performing a test leads to the definition of this set. Different types of tests can detect different types of
defects. Test specification methods have been developed to allow for greater rigor in this activity. A
test aims to highlight the defects of the tested object. Howe ver, it is not intended to correct them. The
definition of a test case attests to the requirements that apply to a specification. An object can only be
tested if it is possible to determine exactly the expected behavior depending on the conditions to which
it is subjected. If the specification does not allow this determination, the software property it defines
cannot be tested. Subjecting the specification to this "testability" constraint improves its accuracy, as
it requires an explanation of the object's characteristics. In turn, it may find specification errors earlier.
This constraint is reinforced by certain development methods, such as test -driven development. The
software testing activity uses different types and testing techniques to verify that the software complies
with the specifications (product verification) and customer expectations (product validation). It is one
of the software development processes.
4.2 Bug definition
ISTQB defines a defect as an imperfection of a component or system that ma y interfere with
its operation. This defect is triggered by a system failure or in other words by a deviation from the
expected behavior or result.
This definition indicates that running the system is not the only way to detect faults. It also
suggests tha t a code may be correct and still present a defect that will only occur during a performance
test, for example. In such a case, the origin of the defect could be an archit ectural or configuration
error. The anomaly term is also often used. It is a generic term that refers as much to an error as to a
defect. Although ISTQB seems to consider that defects are most often caused by human errors, they
can also be the consequence of environmental phenomena (radiation, pollution, magnetism),
modifying the hardware of the tested software.
4.3 The role of the tester and other project members
The tester has a series of attributions, among which:
– to read the documents and understand what needs to be tested, and based on this information
to decide how to test. It is also necessary to inform about the resources needed for software testing;
– to develop and prioritize test cases;
– to perform the testing according to the defined procedures;

– to prepare the reports related to the software testing performed;
– to ensure that the tests have been performed according to the defined standards.
Also, another important aspect for a software tester is to have good communication skills so
that he can interact effectively with the development team.
Of course, in addition to the ro le of the tester, it is important to know the roles and
responsibilities of the entire project members :
Software System Test Manager : creates the SW System Test Plan document that includes the
design of software system tests in the field of qualitative / functional testing, coordinates the different
test phases, distributes test reports to SW Test Manager, SW Project Manager and Projec t Manager,
prepares the test environment , coordinates the testing activity, examines the test conditions, as well
as the hardware and tool part, clarifies all the technical ambiguities between the test team and the
developers.
Test team : analyzes the req uirements, creates the tests, modifies the tests according to the new
requirements, consults the FR (Function Responsible) for clarifications, updates the test document if
it is necessary and of course performs the tests. After completing the tests, it cre ates a final report,
which has the role of showing how many errors were found on the respective functionality and
software. The testing process is divided into functionalities in order to have the highest possible
efficiency in testing.
Software Project Ma nager (SWPM): together with System Test Manager and SW Test
Manager plans the necessary tests and testing purpose throughout the test activity, distributes the
program, stages and project plan in time, provides the test program, clarifies all problems betw een test
teams and development, ensure that all tools and documentation are available before the launch of the
first test phase.
4.4 Quality and testing . Classification of tests
The testing phases in the development cycle of a software product ensure a qua lity level defined
in agreement with the customer. Therefore, a testing procedure can be more or less fine and therefore
the testing effort is more or less important and expensive depending on the level of quality required.
Today, testing professions are d eveloping considerably. This is largely due to awareness of the
complexity or criticality of the products. Therefore, it is important that these different phases are well
integrated into the development cycle based on good practice and streamlining the pro cess.
There are different ways to classify tests. The following is a classification based on three perspectives:
the nature of the object to be tested (perspective closely related to the development cycle), the
accessibility of the object structure and the object property (performance for example). However, these
three perspectives do not allow the classification of the non-regression test . The ISTQB glossary
defines it as intended to highlight, in the unchanged part of the software, errors that have been updated
or introduced by a software change.[1] Therefore, the non -regression test is not limited to a certain
phase of the development cycle. It is also not limited to one type of property to be tested. (en) Standard
glossary of terms used in Software Testing , ISTQB, version 2.0, décembre 2007.
The ISTQB glossary defines a test level as a group of test activities that are organized and
managed together. A level of testing is related to the responsibilities of a project. Four levels of testing
are identified:
 Unit test (component test)
 Integration test (technical test or technical integration test)
 System test (functional test)
 Acceptance test

In addition, we also talk about the upstream test level to designate the levels of unity and
integration, as well as the downstream test level to designate the system and acceptance levels.
A. Classification according to the accessibility of the object structure
– White box test design technique: test design technique, generally functional, based on the
analysis of the internal structure of the componen t or system.
– Black box test design technique: test design technique, functional or not, which is not based
on the analysis of the internal structure of the component or system, but on the definition
of the component or system.

Figure 4.1: Black box testing vs White box testing
By extension, tests resulting from these types of design techniques are commonly referred to
as white box tests (or structural tests) and black box tests. Tests that relate to white box testing verify
the internal structure of the object, for example, the execution of conditional statement branches. Unit
and integration tests are often specified using white box test design techniques. For some types of
software, there are standards that prescribe white box test design techniques to be used. Tests that
relate to black box testing verify the definition of the object. System and acceptance tests are often
specified using black box test design techniques, but there is nothing to prevent the use of these
techniques to define unit or i ntegration tests.
B. Classification according object property
 Function test;
 Performance test;
 Intrusion test;
 User test.
A list of all software features has been established by the ISO 9126 standard.
Excluding extremely simple systems, we can say that it is impossible to fully test a software, because
the number of possible configurations increases exponentially with the number of different situations
that the software may be required to process.

Therefore, the success of the tests does not lead to the concl usion that the software is necessarily
working correctly. However, we try to make sure that, if an error is present, the test highlights it, so
that a good test assurance is ensured.
The following aspects must also be highlighted:
– each point of the progr am must have been tested at least once;
– each possible sequence of program points in an execution must have been tested at least once
(generally impossible);
-each functionality of the application must be verified by at least one test case.
If stronger as surances of proper functioning are desired, formal methods may be used.
Depending on the complexity of the software, complete verification sequences may be
required. These involve project management and all components of the project, beyond the software
itself (process, organization, training, support for change): reception, qualification, certification,
approval, simulation, verification of the adequacy of proper functioning.
4.5 The need of testing
The need to perform the entire testing process is based on several factors, such as: customer
satisfaction, customer confidence by providing quality software, its proper functioning being
highlighted only by testing.
A large majority of errors are due to deficiencies in the specifications, highlighting a percen tage
of 60%. A high share
it also represents design errors, which are about 30%. Programming errors represent the
smallest share, sometimes even below 15%.
An important source of errors is the lack of communication between team members involved
in software development.
Errors detected and fixed in the specification phase cost virtually nothing, but the errors
detected after delivery of the product increases their cost from thousands to millions of dollars
/ euro.
4.6 Functional testing vs. non -functional t esting
A functional test has the task of verifying that the functional requirements are met. Functional
requirements describe the capabilities of a system that a user expects to solve a technical problem using
the system.
The requirements are derived from the business processes to be accepted and from the
descriptions of the system process flows intended for use.
The function test involves testing individual functions and is intended to provide evidence that
all technical requirements that have been placed on the application have been implemented correctly.
A functional test can also be performed in the form of a dynamic test. Here the test cases are
derived using the functional specification of the test object.
The non -functional test is the type of test th at is performed according to the non -functional
requirements. Most criteria are not taken into account in functional testing, so it is used to verify the
readiness of a system. Non -functional requirements are usually those that reflect the quality of the
product. Non -functional tests can be effective using testing tools.
Testing software attributes that are not related to specific user functions or actions, such as
performance, scalability, security, or application behavior under certain restrictions.
Non-functional tests have a major impact on customer and product user satisfaction.

In principle, important non -functional attributes of software systems are used in the non –
functional test. Let's take examples of non -functional requirements: How long does it t ake the software
to complete a task? Or how fast the answer is.
4.7 Manual testing vs Automated testing

Figure 4.2: Manual testing vs Automated testing
Software testing can be realised with both testing methods (the automat ic and also manual
method), but it depends entirely of the project requirement, the budget associated with the pr oject and
the test method which will be more efficient for the project. In order to better understand the two
notions, a compar ison between manual testing and automatic testing will be presented.
Manual testing is the classic testing of software, where te sts are performed manually by a QA
analyst. It is performed in order to detect bugs in the developing software . In manual testing, the tester
verifies all the essential features of the application or represented software. In this process, test cases
are run and test reports are generated without the help of automatic software testing tools.
In automatic software t esting , testers write code in order to automate tests. Automation tools
are used to write test scripts for software validation. The main purpose of automated testing is to save
time in running the test. Automatic testing is based on the pre -scanned test wh ich runs automatically,
in order to compare the actual result with the expected results. This mechanism helps the tester to
determine if the application perform or not as expected. Another important aspect is that automatic
testing allows a repetitive load and regression test to be performed without manual intervention of the
tester. Even if all processes are performed automatically, automation requires a manual effort to create
initial scenarios test.
Comparison between both types of testing :
– Automated tes ting uses automation tools for perform test cases, while in manual testing,
test cases are performed by a tester;
– Automatic testing is faster than manual testing. Also, in manual testing, a biggest number
of people are neede d in order to perform the tests;
– The initial investment is higher in automatic testing, compared to manual testing;
VS

– Automated testing is a safer method because it uses tools and scripts. Manual testing
provides lower safety due to human errors possibility;
– Performance testing is not manually feasible in the case of manual testing. Automatic
testing covers this aspect of performance testing, such as: load testing , stress testing, Spike
testing ;
– Regarding batch testing, manual tests cannot be grouped. Instead, multiple test scripts can
be grouped in automa tic testing for night execution ;
– Also, in the case of automatic testing, knowledge in the field of programming is needed,
which is not necessary in manual testing ;
– Automation testing is useful when performing the same set of test cases frequently, and in
the case of manual testing when the test only needs to run once or twice ;
– In the case of deadlines, automatic tests have zero risk, as opposed to manual test ing where
the risks are higher ;
– From documentation point of view, automatic test s act as a document that provides a source
of documentation, especially for automatic unit testing cases. This is a benefit for a new
developer. In the case of manual testing, the test cases do not pr ovide a source of
documentation ;
– Automatic testing is su itable for regressive testing, testing performance, load testing or
repeatable functional test cases. Instead, manual testing is appropriate for ad hoc
exploration, use and testing. This type of testing should be used if automation changes
frequently ;
Among the advantages of manual testing are:
– Visual feedback is obtained, the scripts from the automatic test not being able to provide
opinions and information about the way interface looks;
– The human element, which means obtaining a feedback that only the human being can
provide and also the ability to predict what customers want or do not want;
– Lower costs in the short term, if a single application is tested only once and many updates
are not expected, manual testing is a favorable option, because it does not involve expensive
software investments;
– Flexible testing. The testing process involves going through the steps of writing, scheduling
and examining test cases for the software which would be tested. However, if we only need
to test a small change, we can resort to manual testing exactly in that moment.
Some of the disadvantages of manual testing are:
– Less secure than automatic testing, due to human errors involved in manual testing,
meaning that running scripts is a more secure option;
– In larger projec ts, the presence of a testing team is n ecessary, but due to repetitive tasks
there is the possibility that the testers make mistakes, human errors also intervening in this
case. Thus, we have an increased chance that the error will not be found;
– They are n ot reusable. If further changes are desired in the application, a manual test will
be required again, in order to be sure that no changes have occurred.

Among the advantages of automated testing are:
– We are able to find more errors than testing manually, due to the fact that scripts that are
more detailed. They allow the coverage of some bugs that the tester may not discover due
to various factors such as inattention, monotony and repeatability of work tasks etc;
– Scriptures are faster, which is why speed a nd efficiency are increased;
– Tests are reusable for frequently updated codes, so test scripts do not need to be rewritten
and can be used in regression tests;

– Give the team time to get an overview. The automation test helps to save time, avoiding
manual te sting, which allows us to have an overview of the entire project and also avoid
human error;
– Easier for the whole team to interpret the final results that for a person who interprets the
manual tests alone.
Some of the disadvantages of automated testing ar e:
– Lack of the human element;
– Due to the lack of the human element, it is not obtained a perspective of the visual elements
of the interface, such as color, size of the buttons, aspects related to the aesthetics of the
interface;
– The tools needed to perfor m automated tests can be expensive.
4.8 Control Area Network (CAN)
The Control Area Network (CAN) was developed by Bosch in 1980, being the most widely
used communications network in this field. In 1994 it became an ISO standard. The main advantage
of CAN is that it is a cheap and durable network that allows communication with several CA N devices
at the same time. CAN was originally designed for car electronics. Currently, it has also applications
in other fields such as industrial networks, automation, medical devices.
On CAN, the transmitted data are segmented into frames , which can be sent periodically or
aperiodically. Each CAN frame is labeled with a number called an identifier , which determines the
priority of the frame during transmission. The CAN network has a decentralized structure and all
network nodes can access the BUS at any time.

Figure 4.3: Multiple nodes on a CAN bus.

To support communication on a multi -master bus, each node has a transceiver and a controller,
CAN being an event -based communication protocol. Two BUS access techniques are used: CSMA /
CA (Carrier Sense Multiple Access / Collision Avoidance) and arbitration technique.

In the CSMA / CA technique, whenever a node in the CAN network wants to transmit a
message, it first checks whether any other node is transmitting on the bus. If there is another
communicati ng node, then refrains from sending the message for a period of time and then checks the
availability of the BUS again. Despite using this technique, if there is still a collision, then the arbitrage
scheme is used to give priority to the sent message.
According to the arbitration scheme, if several nodes transmit the message at the same time,
the node with the highest priority will continue to send the message. Lower priority nodes stop sending
messages.
CAN is a dominant automotive protocol, but it cannot provide real -time performance, which is
essential in critical safety applications and advanced driver assistance systems.
As a solution to this problem, FlexRay was designed using a multiple access mechanism
(TDMA) for critical safety systems. FlexRay is a communications network triggered over time, which
means activities are conducted while time progresses.
The FlexRay network has a flexible topology and can be used as a BUS, star or multistar. In
the star topology, all nodes communicate through a central node. BUS and star topologies can be
combined to form the hybrid topology. Also, FlexRay has the ability to replace multiple high -speed
CAN buses, reducing complexity and costs. The FlexRay standard manages the communication of
several nodes or
ECU via a channel. This is realised with a predefined communication cycle that provides a
predefined space for static and dynamic data.
The FlexRay communication cycle is the basic element of the FlexRay media access scheme.
The cycle time is fixed when the network is designed, being approximately 1 -5 ms. We have four main
parts of a communication cycle: static segment, dynamic segment, symbol window and network idle
time.

Figure 4.4: Communication Cycle.
4.9 CANalyzer and CANoe
CANalyzer and CAN instruments have been developed to meet the basic needs of the module –
based CAN communication protocol, combining a range o f measurement capabilities with the
simulation ones.
Both CANalyzer and CANoe can interface with multiple CAN networks and also provide
accurate time measurements for all communication transfers, including both communication and
communication error messages, with standard playback and recording operations. The two instruments

basically work as a multi -channel oscilloscope, as a multichannel logic analyz er or as a custom
alphanumeric display unit, using an integrated database. Also, CANalyzer and CANoe are able to
create any type of message generation, just like a programmable function generator, with complete
control of all variables, data in the network .
There are two major differences between the two instruments:
 CANoe supports multi -node simulations, which means that if you want to simulate an entire
distributed system that is connected to multiple nodes and interacts in a CAN environment, you
can do t his using only CANoe. CANalyser supports single node simulation, so for a distributed
system you can only simulate a single node, and the rest of the nodes must be physically
connected.
 CANoe also has graphical panels, allowing the creation of buttons, sli ders, check boxes and
also their graphical monitoring. These graphical panels are used in a CAPL program, being
associated with environmental variables.

Figure 4.5: A typical CANoe graphic panel.

As we have already specified, CANalyzer supports the control of a single node, while CANoe
supports the control of a collection of multiple nodes.

Figure 4.6: Control levels of CANalyzer and CANoe nodes

As we specified, CANoe allows us to build test panel interfaces to provide inputs and
outputs. We can add the CAPL software needed to interconnect our devices for proper transmission of
the CAN messages we want the tester to send. Thus, it is easy to connect messages received from CAN
to receive messages to the graphics devices on the front panel. In addit ion, moving counters, flashing
lights and numeric display graphics are easy to create.
4.10 CAPL programming language
Based on the C programming language, CAPL or CAN Access Language Programming is the
programming language used exclusively in the PC -based tool environments of CANalyzer and
CANoe. The original design intent behind it was to respond to the CAN -based distributed embedded
system developer requirements, including: maximum control of all test and measurement operations,
control of system simulati on or CANoe or CANalyzer module, support for one or more communication
channels, ability to connect to other PC applications. CAPL is an event -based procedural language,
including a large number of sp ecial -purpose functions to help distributed built -in sys tem developer.

Although CAPL can be considered a procedural programming language, CAPL can also be
considered as a programming environment.
Figure 4.7: CAPL Software Execution is Event -Driven

In this programming environment , a user can create, modify and maintain CAPL programs that
can interface with a wide variety of inputs, outputs and other funct ions. Start -stop events, events
keyboard input, the ability to send and receive CAN messages, the interaction with the serial por t and
the parallel port, the use of timers and the ability to interconnect with specific DLLs client are some
of the interface options available in programming in the CAPL environment.
Most programs are developed using the CAPL browser, which offers an eas y-to-use
development process called "edit -by-compile". Even if it is provided as an integrated component of
CANalyzer or CANoe, the CAPL application program browser can be used separately.

Figure 4.8: CAPL Interfaces

Figure 4.9: CAPL Responds to Events

5. Implemented of the adopted solution
5.1 An overview of the project
The practical par t is implemented using CANoe in the CAPL code for programming . This
application simulates a car cluster through the CarView panel for the visual part , which can be
controlled and tested from the ControlCar panel. T he functionalities of the car which will be test are:
doors and seatbelts when the car has ignition off and on and has velocity, coolant temperat ure when is
too cold, too hot or in a normal interval and the car tank when it has fuel below the preset limit.
In the figure 5.1 can be observed the application interface with both panels: CarView and
CarControl. Also appear s the Trace panel where are mes sages which contain the signals for each
environment used in application.

Figure 5.1: Application interface

In the CarContol panel , in order to use each control environment you need to start the
simulation from the first button of the panel . From this button you can start and stop the simulation.
Under the start -stop button there is an ignition panel to start the car , it is a switch on -off. When this
switch is off, only the Headlights and Doors buttons can be used and if you wait more than 10 secon ds
the car goes into sleep mode and at this moment the trace is s topped. The car can wake up only if the
headlights are used or doors are opened , but without an action for 10 seconds in which Ignition remains
switches off, the car goes into sleep mode and the trace are not transmitted again.
In the doors panel are two button, one for left door and one for right door. When Left Door
button is used, the result will be opening the left door. This scenario is also valid for the right door.
Also, when you have action on the both buttons for left and right door, the result will be opening the
both doors. When we have action on the door button, this can be verified on Trace, via a signal . The
checked signals are in accordance with the open door, thus having a signal for the right door,
respectivel y another one for the left door: Signal_LeftDoor and Signal_RightDoor , whose value is set

to 1 when we have action on the button . This signals are part from a message :
Message_Lights_Doors_Seatbelt and Message_Ignition. According to the open door, in data will be
saved a value, in this way: for the left door opened, the value is 01, for the right door, the value is 0 2
and in case we have opened both door, the value will be 03. Also, another important aspect is when
we have both doors open, because this is signaled by the appearance of a warning. In figure 5.2 it is
represented the warning which appears.

Figure 5.2: Warning Door s

In the seatbelts panel the configuration was made similar to doors panel, so it was used two
buttons: Left Seatbelt and Right Seatbelt. This use case is extremely important in order to ensure the
safety aspect , which must be one targeted in automotive field. When you press the button for both left
and right seatbelts, but also in both cases, a warning will appear, indicating that the seatbelt is not used.
This warning is represented in figure 5.3.

Figure 5.3: Warning Seatbelts

Another step of the project was the creation of the RPM and Speed scenarios. At Ignition on,
RPM take s 900 value and the speed value can be set according to user preferences . In the opposite
case, at Ignition off, the both value for RPM and speed are in zero point of the scale. The value for
RPM and speed can be checked on Trace, by us ing Signal_RPM and Signal_Speed, from
Message_Speed_RPM. The analogic representation for spe ed and RPM can be observed in figure 5.4
and 5.5. Also, Speed has a digital representation, which can be observed in figure 5.6.
The acoustic aspect was also a very important part of the project, which appears when we have
speed and a door is opened or a seatbelt is not used. Also, these signal s can be checked on Trace:
Signal_AcusticSeatbelt and Signal_AcusticDoors. The acoustic sound is heard only when Ignition is
on.

Figure 5.4: Speed representation Figure 5.5: RPM representation

Figure 5.6: Digital Speed representation

The project continued with the implementation of the Coolant Temperature part, which can
takes values between 40 and more tha n 120 degrees, in CarView Panel, but from CarControl Panel,
we can receive values between -40 and 215 degrees, values which can appear on Trace.
There are two limits: one lower and one higher. The lower one is at -40 degrees and the upper
one appears at values higher than 120 degrees. The representation for CoolantTemp erature is visible
in figure 5.7 . At the lower limit, a warning is triggered which indicates that the car is at too low
temperature. This w arning can be seen in figure 5.8 . Of course, in the opposite case, when the car is at
too high temperature, this is signaled by another wa rning, represented in figure 5.9 .

Figure 5.7 : CoolantTemperature

Figure 5.8: Lower Temperature Warning Figure 5.9: Higher Temperature Warning

The fuel representation was made in the range of values 0 and 40 liters, which can be seen in
figure 5.10. The capacity of the tank is at the maximum value of 40 liters and if we have a limit of less
than 5 liters, this triggers a warning, which is represented in Figure 5.11.

Figure 5.10: Fuel representation

Figure 5.11: Tank warning

The car's headlights are another part of the project. The implementation is based on the
following scenarios: for the value 0 and 3, the headlights are off, for the value 1, it is represented the
low beam, and for the value 2, the high beam. Also, headlights can go through all states, not being
dependent on Ignition behavior. The re prese ntation for the headlights can be observed in figure 5.12.
5.13 and 5.14. Also, for low beam case and high beam appear a specific icon, according to the chosen
scena rio.

Figure 5.12: Headlights

Figure 5.13: Low Beam Figure 5.14: high Beam

5.2 Panel Designer

Part 5.1 of the project presented the operation of the application and part 5.2 is destined to
explain how each panel was configured. Designer Panel has the role in the visual implementation of
the application, by assigning the specific values to each representation, here entering the part of color,
size, lower and upper limits, symbols, dimensions, as well as positioning and assigning c ontrol values.
This offers a major advantage, as the user can change the application interface at any time and adjust
it aesthetically and visually. The first step is to create a new configuration from File -> New ->
Configuration, as can be seen in the figure 5.15. After this step, the application continues with the
addition of a node, as follows: right click on the left side (on lines), then Insert Network Node. The
result can be seen in the figure 5.16. The application was made with a single node, but there are also
variants that involve several nodes.

Figure 5.15: Creation of a new configuration

Figure 5.16: Result after node creation

Using the Tools -> Panel Designer option, the blocks were created. In this case, were made 2
blocks: Car Control and CarView. In the following will be presented captures regarding the
configuration of each element of the application. From the Toolbox, each control element from the

CarControl and Carview panels was used, and Proporties has the role of modeling the control elements
used. The representation can be observed in figure 5.17.

Figure 5.17: ToolBox and Properties

Figure 5.17: Properties Panel for Ignition Figure 5.18: Group Box

For Ignition Button was used a switch/indicator. The envierement env_KL_15 was used to
control the Ignition button. Also, a group box was used to incorporate the button, which can be
observed in figure 5.18.

Figure 5.19: Properties Panel for Left Door Figure 5.20: Properties Panel for Right Door

Figure 5.21: Properties Panel for Left Seatbelt and Right Seatbelt

For Doors and Seatbelts , as control element was used a checkbox and for the checkbox control
were used the next environments: env_LeftDoor, env_RightDoor, env_LeftSeatbelt and
env_RightSeatbelt.

Figure 5.22: Prope rties Panel for Speed Figure 5.23: Properties Panel for RPM

For Speed and RPM Panel were used env_Speed and env_RPM enivironments. Also, for
Speed, RPM, Fuel and EngineTemp was used from Tools a Track Bar, which allows the user to change
the value in a selected range.

Figure 5.24: Properties Panel for Fuel Figure 5.25: Properties Panel for Coolant Temp.

Figure 5.26: Properties Panel for Headlights

In order to implements the control for headlights, it was used a input/output box, which, which
allows the user to change the value from 4 predefined scenarios .
All elements from CarView are controled by the elements from ControlCar . In the following,
screenshots will be presented for the elements in CarView, which use different environments.

Figure 5.27: Properties Panel for RPM Figure 5.28: Properties Panel for Speed

Figure 5.29: Properties Panel for Coolant Temp. Figure 5.30: Properties Panel for Fuel

For Speed, RPM, F uel and Coolant Temperature was used Analog Gauge from Toolbox.

Figure 5.31: Properties Panel for Seatbelt and Open Doors Warning

Figure 5.31: Properties Panel for Coolant Cold and Hot Warning

Figure 5.32: Properties Panel for Low and High Beam

Figure 5.33: Properties Panel for Fuel Warning Figure 5.34: Properties Panel for Acoustic

For icons which have picture representation were used Picture Box and for the Acoustic was used
Media Player from Toolbox.

5.3 Database

The first step that was considered was the environment creation, that was m ade from Tools –
>CANdb++ Editor. A capture with this step is represented in figure 5.35. This is also valable for
messages and signal s creation.

Figure 5.35: Environment creation

Editing an environment is made in this way: after environment creation, right click on the
environment and then click on edit environment variable . Figure 5.36 is a representation of the edits
that can be made for an environment .

Figure 5.36: Edits for the environment

In order to edit signals, the process can be made in this way: right click on the signal and then
click on edit signal. The edits which can be made on a signal are represented in figure 5.37.

Figure 5.37: Edits for the signal

In order to edit message , the process is similar, so it is necessary to press right click in the
message and then click on edit message. The result can be observed in figure 5.38.

Figure 5.38: Edits for a message

DLC represents the length of a message and 1 DLC=1 B yte. A message can have a maximum
of 8 DLC, which represents 64 bits. Depending on the value of a signal, it will occupy a certain number
of bits of the message. The number of bits occupied by each signal in a message appears in the message
layout. In figure 5.39 appears the layout.

Figure 5.39: Layout representation

For each signal you can realise positionate in the layout. As can be seen in the example in
Figure 5.39, the message has a length of 3 DLC: on the first DLC was assigned the signal
Signal_Headlights, which can take values between 0 and 3, a value that can be represented on two bits
of the message , so the remaining bits of the first DLC remain unused; on the second DLC the signals
of Signal_LeftDoor, Signal_RightDoor and Signal_Acou sticDoors were assigned, each occupying one
bit, remaining 5 unused bits from the DLC and on the last DLC, the signals Signal_LeftSeatbelt,
Signal_RightSeatbelt and Signal_AcousticSeatbelts were assignated, remaining again 5 unused bits.

5.4 CAPL Code implementation

The implementation of the application was based on a graphical interface, but also a code
writing part. The code part was implemented in CAPL, a language similar to language C. Using code
was possible to control the elements from the panel s, using the environments, signals and messages
from the Database. Also, the code was implemented only on the Code node, because it does not have
a high complexity .
Code implementation began by declaring global variables, messages, and timers. They have a
representative name that suggested a connection between the display and the control . Global variables
link environmental from panels CarControl and CarView and give the value of the signals in the
messages . The timers help messages refresh the value of sig nals, value is refreshed cyclic at the time
which was setted . The declaration of global variables is represented in figure 5.40.

Figure 5.40: Declaration of variables

The environment control was made with the help of the function on envVar which is call when
it is action on the button. The representative code for a button action can be observed in figure 5.41.
In function on envVar, the value of the respective environment is taken in a global variable and the
function in which the value of the environment is used is called. After that, the timer of the signal that
will be sent on the trace is set, by using setTimer function.

Figure 5.41: Code for button action

Using function on timer it is possible it is possible to send trace messages at certain time
intervals . The first time the signals in th e message are assigned the corresponding values, then the
output function is called , to update the values of the signals in the message. After this, the timer of the
signal is set to trace and transmitted cyclically. The code is represented in figure 5.42.

Figure 5.41: Code for timer

6. Experimental Results
6.1 The f irst scenario of testing:
Input:
1. Ignition off , set Left Door and set Right Door .

Expected Result:
1. Both doors are open, DoorWarning is displayed and the signals: Signal_LeftDoor and
Signal_RightDoor from Message _Ignition are 1.

Result:

Figure 6.1: The f irst scenario – CarControl and Trace

Figure 6.2: The f irst scenario – CarV iew

6.2 The s econd scenario of testing:
Input:
1. Ignition on , set Left Door and set Right Door , set Left Seatbelt and Right Seatbelt, Velocity
= 60 km and RPM=5000 .

Expected Result:
1. Both doors are open, DoorWarning and SeatbeltWarning are displayed and the signals:
Signal_LeftDoor , Signal_RightDoor , Signal_LeftSeatbelt and Signal_RightSeatbelt from
Message_Lights_Doors_Seatbelt are 1 , just Signal_HeadLights is 0 , Signal_Speed is 60
and Signal_RPM=5000 from Message_Speed_RPM and from Messag e_Ignition all signals
are 1 and acustic warnings can be heard.

Result:

Figure 6.3: the second scenario – CarControl and Trace

Figure 6. 4: The s econd scenario – CarView

6.3 The t hird scenario of testing:
Input:
1. Ignition on , set Fuel = 20 and EngineTemp = -40
2. Ignition on, set Fuel = 5 and EngineTemp = 130

Expected Result:
1. The tank is half full , temperature is displayed to 40șС but on Signal_CoolantTemp is -40
and a warning for low temperature is displayed, Signal_Fuel = 20 and Signal_CoolantTe mp
= -40.
2. The tank is almost minim, temperature is displayed more than 120șС but on
Signal_CoolantTemp is 130 and a warning for high temperature is displayed, Signal_Fuel
= 5 and Signal_CoolantTemp = 130.

Result:

Figure 6. 5: The third scenario – CarControl and Trace for step 1

Figure 6. 6: The third scenario – CarView for step 1

Figure 6. 7: The third scenario – CarControl and Trace for step 2

Figure 6. 8: The third scenario – CarView for step 2
6.4 The f ourth scenario of testing:
Input:
1. Ignition on , set Headlights = 1 and RPM = 1000
2. Ignition off and set Headlights = 2

Expected Result:
1. The car’s headlights are on, a low beam icon is displayed and RPM = 1000
2. The car’s headlights are on, a high beam i con is dis played, RPM = 0 and Signal_Headlights
is 1

Result:

Figure 6. 9: The f ourth scenario – CarControl and Trace for step 1

Figure 6. 10: The f ourth scenario – CarView for step 1

Figure 6. 11: The f ourth scenario – CarControl and Trace for step 2

Figure 6. 12: The f ourth scenario – CarView for step 2
6.5 The fifth scenario of testing:
Input:
1. Ignition on , set Headlights = 1, set Left Door = 1, Left Seatbelt = 1, CoolantTemp > 120, Fuel
< 5 and Velocity > 0
2. Ignition off

Expected Result:
1. The car’s headlights are on, a low beam icon is displayed , Left Door is opened, warnings for:
door, oil temperature and tank are displayed and Velocity > 0

2. The car’s headlights are on, Left Door is opened and door warning is displayed, velocity = 0
and jus Message_i gnition is send on Trace
Result:

Figure 6. 13: The f ifth scenario – CarControl and Trace for step 1

Figure 6. 14: The fifth scenario – CarView for step 1

Figure 6. 15: The fifth scenario – CarControl and Trace for step 2

Figure 6. 16: The fifth scenario – CarView for step 2

7. Conclusions
Software testing is a guided investigation in order to obtain information about the quality of
the software product made in the previous stages, its main purpose being the discovery of software
bugs. Also, software testing is an important step in software development because 40 -50% of efforts
are directed in this direction, especially for software products that req uire a high degree of security.
The automotive field is of great interest, especially nowadays when we live in a world that is
evolving every day, especially in the field of information technology.
The choice of this theme is due to the fact that although testing is a separate stage, it is strongly
dependent of the development stage, based on soft ware development methods. Although testing cannot
100% demonstrate that the product is working properly in any conditions, it is extremely important
because it demonstrates that the product is not working properly under certain conditions, which
obviously will reduce the number of errors.
Errors can occur not only due to the wrong code, but also due to gaps, ambiguities in
requirements or incomplete requirements. This will lead to errors that occur from the design phase by
the program designer. Another impo rtant cause that can lead to an error is the compatibility problem,
which can be caused by the interaction with other applications or running on different hardware
systems and due to nonconformities that occur from one version to another in the developmen t process.
Ideally, the purpose of testing is to detect and eliminate all errors in a program, but as we have
already said, this is impossible. In reality, the main purpose is to detect errors, correct those that can
be eliminated, minimize those that cann ot be eliminated or ignore it if the error cannot be eliminated
or the cost of fixing the error is higher than the cost due to it. The purpose of the test is also to provide
the user with assurance that the product is in compliance with the requirements.
In this paper we discussed testing in the field of automotive engineering, the purpose being to
familiarize with the specific notions of the field and to present an application that allows interaction
with various test scenarios in the automotive field. It was desired to obtain conclusive results, in
accordance with reality and to create plausible test scenarios. The purpose of the project was to create
an application that allows interaction with the user, so as to arouse the interest of testing diverse
scenarios as possible. Also, t he paper involved both stages of obtaining the software product, including
the part of developing and writing code, as well as the part of testing and error detection. Of course,
while testing the application, many errors were discovered, which required subsequent changes in the
code, so that the final product provided the correct results. It is important to mention that the purpose
of the project was not only to create an application in the automotive field, but also to demons trate the
need for testing in order to obtain satisfactory results.

9. Annexes

variables
{
int global_RightDoor;
int global_LeftDoor;
int global_KL15ON;
int global_Speed_Value;
int global_RPM_Value;
int global_SeatbeltWarning;
int global_LeftSeatBelt;
int global_RightSeatBelt;
int global_WarningDoors;
int global_CoolantTemp;
int global_Fuel;
int global_Headlights;
int global_counter=0;

msTimer T1;
msTimer T2;
msTimer T3;
msTimer T4;

message Message_Speed_RPM M1;
message Message_Temp_Fuel M2;
message Message_Lights_Doors_Seatbelt M3;
message Message_Ignition M4;

}

on envVar env_RightDoor
{
global_RightDoor=getValue( this);
OpenDoors();
setTimer(T4,500);
}

on envVar env_LeftDo or
{
global_LeftDoor=getValue( this);
OpenDoors();
setTimer(T4,500);
}

void OpenDoors()
{
setControlVisibility( "CarView" ,"OpenDoors" ,0);
setControlVisibility( "CarView" ,"RightDoor" ,0);
setControlVisibility( "CarView" ,"LeftDoor" ,0);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,0);
putValue(env_SoundDoors,0);

if (global_RightDoor==1 && global_LeftDoor==1 && global_Speed_Value>10)
{
setControlVisibility( "CarView" ,"OpenDoors" ,1);

setControlVisibility( "CarView" ,"RightDoor" ,0);
setControlVisibility( "CarView" ,"LeftDoor" ,0);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,1);
}

if (global_RightDoor==1 && global_LeftDoor==0 && global_Speed_Value>10)
{
setContro lVisibility( "CarView" ,"OpenDoors" ,0);
setControlVisibility( "CarView" ,"RightDoor" ,1);
setControlVisibility( "CarView" ,"LeftDoor" ,0);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,1);
}

if (global_RightDo or==0 && global_LeftDoor==1 && global_Speed_Value>10)
{
setControlVisibility( "CarView" ,"OpenDoors" ,0);
setControlVisibility( "CarView" ,"RightDoor" ,0);
setControlVisibility( "CarView" ,"LeftDoor" ,1);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,1);
}

if (global_RightDoor==1 && global_LeftDoor==1 && global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"OpenDoors" ,1);
setControlVisibility( "CarView" ,"RightDoor" ,0);
setContr olVisibility( "CarView" ,"LeftDoor" ,0);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,0);
}

if (global_RightDoor==1 && global_LeftDoor==0 && global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"OpenDoors",0);
setControlVisibility( "CarView" ,"RightDoor" ,1);
setControlVisibility( "CarView" ,"LeftDoor" ,0);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,0);
}
if (global_RightDoor==0 && global_LeftDoor==1 && global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"OpenDoors" ,0);
setControlVisibility( "CarView" ,"RightDoor" ,0);
setControlVisibility( "CarView" ,"LeftDoor" ,1);
setControlVisibility( "CarView" ,"OpenDoorsWarning" ,1);
putValue(env_SoundDoors,0);
}
}

on envVar env_KL15
{
global_KL15ON=getValue( this);
if(global_KL15ON)
{
global_RightSeatBelt=0;
global_LeftSeatBelt=0;
global_RPM_Value=900;

global_Speed_Value=0;

putValue(env_SpeedView,global_Speed_Value);
putValue(env_RPMView,global_RPM_Value);
putValue(env_Speed,global_Speed_Value);
putValue(env_RPM,global_RPM_Value);
putValue(env_CoolantTemp,0);
putValue(env_CoolantTempView,10);
putValue(env_FuelView,20);
putValue(env_Fuel,20);
putValue(env_LeftSeatBelt,0);
putValue(env_RightSeatBelt,0);
putValue(env_SoundDoors,0);
putValue(env_SoundSeatbelt,0);

setControlVisibility( "CarView" ,"FuelWarning" ,0);
setControlVisibility( "CarView" ,"CoolantWarningH" ,0);
setControlVisibility( "CarView" ,"CoolantWarningC" ,0);
setControlVisibility( "CarView" ,"SeatBeltWarning" ,0);

setTimer(T1,100);
setTimer(T2,100);
setTimer(T3,100);
setTimer(T 4,500);
}
else
{
global_RightSeatBelt=0;
global_LeftSeatBelt=0;
global_RPM_Value=0;
global_Speed_Value=0;

putValue(env_RPMView,0);
putValue(env_SpeedView,0);
putValue(env_Speed,0);
putValue(env_CoolantTemp,0);
putValue(env_CoolantTempView,0);
putValue(env_FuelView,0);
putValue(env_Fuel,0);
putValue(env_LeftSeatBelt,0);
putValue(env_RightSeatBelt,0);
putValue(env_SoundDoors,0);
putValue(env_SoundSeatbelt,0);

setControlVisibility( "CarView" ,"FuelWarning" ,0);
setControlVisibility( "CarView" ,"CoolantWarningH" ,0);
setControlVisibility( "CarView" ,"CoolantWarningC" ,0);
setControlVisibility( "CarView" ,"SeatBeltWarning" ,0);

cancelTimer(T1);
cancelTimer(T2);
cancelTimer(T3);
setTimer(T4,500);
}
}

on envVar env_RightSeatBelt
{

if(global_KL15ON==1)
{
global_RightSeatBelt=getValue( this);
SeatBelt();
}
}

on envVar env_LeftSeatBelt
{

if(global_KL15ON==1)
{
global_LeftSeatBelt=getValue( this);
SeatBelt();
}
}

void SeatBelt()
{
if(global_LeftSeatBelt==1 && global_RightSeatBelt==1 &&
global_Speed_Value>10)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,1);
putValue(env_SoundSeatbelt,1);
}

if(global_LeftSeatBelt==1 && global_RightSeatBelt==0 &&
global_Speed_Value>10)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,1);
putValue(env_SoundSeatbelt,1);
}

if(global_LeftSeatBelt==0 && global_RightSeatBe lt==1 &&
global_Speed_Value>10)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,1);
putValue(env_SoundSeatbelt,1);
}

if(global_LeftSeatBelt==1 && global_RightSeatBelt==1 &&
global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,1);
putValue(env_SoundSeatbelt,0);
}

if(global_LeftSeatBelt==0 && global_RightSeatBelt==1 &&
global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"SeatBeltW arning",1);
putValue(env_SoundSeatbelt,0);
}

if(global_LeftSeatBelt==1 && global_RightSeatBelt==0 &&
global_Speed_Value<=10)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,1);
putValue(env_SoundSeatbelt,0) ;

}

if(global_LeftSeatBelt==0 && global_RightSeatBelt==0)
{
setControlVisibility( "CarView" ,"SeatBeltWarning" ,0);
putValue(env_SoundSeatbelt,0);
}
}

on envVar env_Speed
{
if(global_KL15ON)
{
global_Speed_Value=getValue( this);
putValue(env_SpeedView,global_Speed_Value);

if(global_Speed_Value>0 && global_RightSeatBelt==1 && global_LeftSeatBelt==1)
{
SeatBelt();
}
if(global_Speed_Value>0 && global_LeftSeatBelt== 0 && global_RightSeatBelt==1)
{
SeatBelt();
}
if(global_Speed_Value>0 && global_RightSeatBelt==0 && global_LeftSeatBelt==1)
{
SeatBelt();
}
if(global_Speed_Value==0)
{
SeatBelt();
}

if(global_Speed _Value>0 && global_RightDoor==1 && global_LeftDoor==1)
{
OpenDoors();
}
if(global_Speed_Value>0 && global_LeftDoor==0 && global_RightDoor==1)
{
OpenDoors();
}
if(global_Speed_Value>0 && global_RightDoor==0 && global_LeftDoor==1)
{
OpenDoors();
}
if(global_Speed_Value==0)
{
OpenDoors();
}
}
}

on timer T1
{
M1.Signal_Speed=global_Speed_Value;
M1.Signal_RPM=global_RPM_Value;
output(M1);
setTimer(T1,100);

}

on envVar env_RPM
{
if(global_KL15ON)
{
global_RPM_Value=getValue( this);
putValue(env_RPMView,global_RPM_Value);
}
}
on timer T2
{
M2.Signal_Fuel=global_Fuel;
M2.Signal_CoolantTemp=global_CoolantTemp;
output(M2);
setTimer(T2,100);
}
on envVar env_CoolantTemp
{
if(global_KL15ON)
{
global_CoolantTemp=getValue( this);
putValue(env_CoolantTempView,global_CoolantTemp);
CoolantTemp();
}
}

void CoolantTemp()
{
if(global_CoolantTemp>120)
{
setControlVisibility( "CarView" ,"CoolantWarningH" ,1);
}
else
{
setControlVisibility( "CarView" ,"CoolantWarningH" ,0);
}

if(global_CoolantTemp<= -40)
{
setControlVisibility( "CarView" ,"CoolantWarningC" ,1);
}
else
{
setControlVisibility( "CarView" ,"CoolantWarningC" ,0);
}
}

on envVar env_Fuel
{
if(global_KL15ON)
{
global_Fuel=getValue( this);
putValue(env_FuelView,global_Fuel);
Fuel();
}
}

void Fuel()

{
if(global_Fuel<5.1)
setControlVisibility( "CarView" ,"FuelWarning" ,1);
else
setContr olVisibility( "CarView" ,"FuelWarning" ,0);
}

on envVar env_Headlights
{
global_Headlights=getValue( this);

setControlVisibility( "CarView" ,"LightOn" ,0);
setControlVisibility( "CarView" ,"LowBeam" ,0);
setControlVisibility( "CarView" ,"HighBeam" ,0);

if(global_Headlights==1)
{
setControlVisibility( "CarView" ,"LightOn" ,1);
setControlVisibility( "CarView" ,"LowBeam" ,1);
}

if(global_Headlights==2)
{
setControlVisibility( "CarView" ,"LightOn" ,1);
setControlVisibility( "CarView" ,"HighBeam",1);
}
setTimer(T4,500);
}
on timer T3
{
M3.Signal_LeftDoor=global_LeftDoor;
M3.Signal_RightDoor=global_RightDoor;
M3.Signal_LeftSeatbelt=global_LeftSeatBelt;
M3.Signal_RightSeatbelt=global_RightSeatBelt;
M3.Signal_HeadLights=global_He adlights;
M3.Signal_AcusticSeatbelt=getValue(env_SoundSeatbelt);
M3.Signal_AcusticDoors=getValue(env_SoundDoors);
output(M3);
setTimer(T3,100);
}
on timer T4
{
M4.Signal_Ignition=global_KL15ON;
M4.Signal_LeftDoor=global_LeftDoor;
M4.Signal_RightDoor=global_RightDoor;
M4.Signal_HeadLights=global_Headlights;
output(M4);
setTimer(T4,500);

if (global_KL15ON==0)
{
global_counter++;
if(global_counter>=20)
{
global_counter=0;
cancelTimer(T4);
}
}
}