Analysis Document
The tachograph example
In «Industrial software homologation. Theory and case study;
Analysis of the European tachograph technology with EU transport Regulations
3821/85, 799/2006 and 561/06 and their consequences for European Citizens you will
find a detailed analysis of potential problems linked to non-verified software.
It features:
- Technological roots and causes of the problem.
- In-depth and comprehensive case studies.
- Real examples from EU tachograph technology.
The scientific paper “Industrial software homologation. Theory and
case study; Analysis of the European
tachograph technology with EU transport Regulations 3821/85, 799/2006 and 561/06 and their consequences for
European Citizens” deals with potential problems associated with non-verified software in tachographs and also
presents the first workable solution to the issue using the formal verification of software. Some of the highlights include-in depth analysis of the following:
tachograph technology with EU transport Regulations 3821/85, 799/2006 and 561/06 and their consequences for
European Citizens” deals with potential problems associated with non-verified software in tachographs and also
presents the first workable solution to the issue using the formal verification of software. Some of the highlights include-in depth analysis of the following:
- leap seconds are a key part of the UTC time standard, yet Microsoft's DateTime library does not incorporate them.
- Alarmingly, Microsoft's DateTime library is used by all enforcement agency tachograph analysis software to convert TimeReal numbers recorded by the tachograph into UTC time.
(Chapter 15 - UNIX-UTC problem)
- Contradiction in UTC - Unix Time: Tachograph data is measured and calculated according to the Unix standards however disturbingly the legislative framework provides for UTC standards. Analysis of data and the ruinous financial outcomes.
(Chapter 15 - UNIX-UTC problem)
- Errors in the application of the minute rule – that the longest continuous activity in a minute will be logged as that activity - along with dialogue of the devastating financial penalties.
(Chapter 14 The definition of driving time: specific software
analysis through different versions)
- Tachographs also have black holes! Discussion on the random registering of driver activities, (including driving time!) depending on how time is calculated.
- We do not know if time registered as DRIVING in Unix format by the tachograph, should actually be REST or DRIVING in the equivalent calendar minutes in UTC format.
(Chapter 15 - UNIX-UTC problem)
- Expert technical and legal digest on impossible and erroneous recording values from EU tachographs.
- More than 20 European case studies with resulting fines.
- Commentary on the unjust and inappropriate outcomes suffered by European citizens, drivers and companies.
What is DRIVING TIME duration in an interval?
Close investigation of the legal texts reveals that there is no definition of driving time duration in an interval in 3821/85 or in 799/2016.
How can that be possible?
Driving time is the central notion of the tachograph business. How has the tachograph calculated the daily driving time without a proper definition?
Close investigation of the legal texts reveals that there is no definition of driving time duration in an interval in 3821/85 or in 799/2016.
How can that be possible?
Driving time is the central notion of the tachograph business. How has the tachograph calculated the daily driving time without a proper definition?
(Chapter 15 - UNIX-UTC problem)
In publishing online «Industrial software homologation. Theory and
case study», we are proud to introduce the first workable proposal
for a solution using formal verification of software.
This scientific document has been developed by Formal Vindications
S.L. in collaboration with the University of Barcelona.
Please select prefered language for your documentation
A similar analysis for the USA and Canada
ELDs: