Software development
My qualifications: a short overview ...
In connection with the subject of exhaust gases from diesel engines ("Dieselgate", Volkswagen emissions scandal, although other manufacturers are often worse) software analysis of engine control units (ECU) is possible, which is a small computer dedicated to steering the engine, running its own software. As a "Certified and Recognized Expert for Software Development (DESAG)", I am commissioned by various courts to do this. In the meantime it is quite common that a court commissions an software expert together with a motor vehicle expert for exhaust gas measurements, in order to approach the question of evidence in an interdisciplinary way. In doing so, I use various methods of software engineering/computer science, e.g. reverse engineering and statistical analysis.
Diesel engines from various manufacturers hit the headlines because, although their vehicles had passed the prescribed tests for official type approval in accordance with the Euro5 or Euro 6a, 6b, 6c,
they showed significantly higher emissions of the irritant gas nitrogen oxides (NOx) during different driving cycles or when driving on the road.
The type test used a simple, "new European" NEDC driving cycle on a roller dynamometer to measure the pollutants emitted in the exhaust gas. The sequence of the
test drive is precisely specified to ensure good comparability. Unfortunately, the manufacturer Volkswagen, for example, used this knowledge with the EA189 engine to identify the test cycle and
adapt the engine control to it, so that the engine behaved differently in this test than in reality.
In the meantime, an improved WLTP driving cycle is used on the chassis dynamometer, which places more realistic demands on the engine. In addition, since the Euro 6d exhaust emission standard
a real drive on the road with a mobile measurement system (PEMS) is also carried out (RDE test drive). This has led to better control and thus to a strong improvement in the exhaust
of exhaust emissions in practical use.
To achieve this, however, engine manufacturers had to make considerable development efforts, because the reduction of NOx conflicts to a certain extent with the desire for low fuel consumption,
low particulate matter emissions, and low costs (simple engine design, low manufacturing and maintenance costs). Modern vehicles now comply well with the legal limits;
to this end, an additional NOx storage catalytic converter, an SCR catalytic converter system (uses AdBlue additive) or both are now usually installed behind the engine.
Small contemplation: How can we get reliable and easy-to-maintain software code?
Image sources: Snippet of function diagram: Moritz Contag*, Guo Lit et. al., 2017-05-01, 2017 IEEE Symposium on Security and Privacy, 10.1109/SP.2017.66 Other images: own material if not (hold mouse over image) a source is specified directly at the image.
My qualifications: a short overview ...
- As a PhD physicist and senior software developer yout get "two experts in one"
- You profit from my experience of more than 20 years of professional software development
as freelancer. Also before I have programmed several years in university research.
- "Clean code" software is your reliable basis for the future. Neither perfectionism nor technical
dept are acceptable: like a growing burden of debts it threatens your software development efforts.
Instead it is desirable to have a code which has a transparent structure, is reliable and easy to maintain.
- Analysis, design, implementation, documentation, tests, user training are all part
of my experience
- C/C++, Java, script languages (Python, shell, awk, Perl, make, Ruby), html + xml, version and change management,
on UNIX, Linux, Windows
- Specialities: university and industry research, logistics,
automotive/factory steering, image analysis in difficult scenery, X-ray and millimeter wave optics,
performance tuning, analysis of engine control unit software (e.g. ECU of diesel engines), reverse engineering, source code quality
In connection with the subject of exhaust gases from diesel engines ("Dieselgate", Volkswagen emissions scandal, although other manufacturers are often worse) software analysis of engine control units (ECU) is possible, which is a small computer dedicated to steering the engine, running its own software. As a "Certified and Recognized Expert for Software Development (DESAG)", I am commissioned by various courts to do this. In the meantime it is quite common that a court commissions an software expert together with a motor vehicle expert for exhaust gas measurements, in order to approach the question of evidence in an interdisciplinary way. In doing so, I use various methods of software engineering/computer science, e.g. reverse engineering and statistical analysis.
Diesel engines from various manufacturers hit the headlines because, although their vehicles had passed the prescribed tests for official type approval in accordance with the Euro5 or Euro 6a, 6b, 6c,
they showed significantly higher emissions of the irritant gas nitrogen oxides (NOx) during different driving cycles or when driving on the road.
The type test used a simple, "new European" NEDC driving cycle on a roller dynamometer to measure the pollutants emitted in the exhaust gas. The sequence of the
test drive is precisely specified to ensure good comparability. Unfortunately, the manufacturer Volkswagen, for example, used this knowledge with the EA189 engine to identify the test cycle and
adapt the engine control to it, so that the engine behaved differently in this test than in reality.
In the meantime, an improved WLTP driving cycle is used on the chassis dynamometer, which places more realistic demands on the engine. In addition, since the Euro 6d exhaust emission standard
a real drive on the road with a mobile measurement system (PEMS) is also carried out (RDE test drive). This has led to better control and thus to a strong improvement in the exhaust
of exhaust emissions in practical use.
To achieve this, however, engine manufacturers had to make considerable development efforts, because the reduction of NOx conflicts to a certain extent with the desire for low fuel consumption,
low particulate matter emissions, and low costs (simple engine design, low manufacturing and maintenance costs). Modern vehicles now comply well with the legal limits;
to this end, an additional NOx storage catalytic converter, an SCR catalytic converter system (uses AdBlue additive) or both are now usually installed behind the engine.
Small contemplation: How can we get reliable and easy-to-maintain software code?When did you last have this thought or feeling?
- "We should quickly cleanup this part of the software, we will run into trouble here".
- This interface should be documented in a better way.
- These software modules are entangledi, this is not healty
- Our coding standard is really helpful
- this part of the code has poor test coverage. The existing tests are not really meaningful.
- The documentation is outdated, important concepts are not documented and can only be found in some e-mails.
- now it has taken days to locate this bug. We could have saved ourselves that if we ...
- This project was so chaotic, we had so many unexpected difficulties, and to finish it iwe really screwed up some parts.
- This event did not help the company culture and the team.
- All departments of the company are under pressure, this is the reason there is often bickering.
- I am thankful for the open and communication and the good cooperation in my team: I could solve this problem really fast.
Technical debts is a metaphor for the possible consequences of "bad" software: the implied cost of additional rework caused by choosing too simple, problematic code. It will cause extra effort when changes and enhancements have to be done. of the software. To stay in a "positive zone" and not glitch into technical debt, not only developers but also project managers are responsible. They try to "keep up the spirit" also in times of difficult outer conditions:
- Follow common state-of-the-art design principles
- A well thought-out concept of code standards that is also lived by the developers
- Meaningful level of documentation that is regularly maintained and accessible to all team members
- Good infrastructure
- Good code coverage of tests
- Clear structure of the source code
- Common "best practice" strategies are familiar to all members of the team
- Static source code analysis and attention to compiler warnings
- Open and trusting teamwork and a good error culture
- A balance between an agile approach and anticipation of future requirements
- Sensible weighting of short-term requirements of the current project and long-term success
- Pleasant external working conditions: climate, brightness, no noise, enough work space
- Continuous Integration (CI) process and use of software metrics
Image sources: Snippet of function diagram: Moritz Contag*, Guo Lit et. al., 2017-05-01, 2017 IEEE Symposium on Security and Privacy, 10.1109/SP.2017.66 Other images: own material if not (hold mouse over image) a source is specified directly at the image.