AUTOSAR and Automotive Engineering

We do it because we want to!

It is about finding purpose and pursuing the enjoyment of achievement. Sometimes that pursuit might be completed in a couple of hours or by the time you say “Yeah!” and look at the clock it is 3am in your timezone. But let’s face it, if you were up long and late, not because you were passionate about conquering that bug, completing that last line of code or figuring out how it should have worked, then you should be asleep (or partying hard) or doing something that is important to you!

Our folks spend most of their time working in an area in the Automotive sector, specifically on Automotive Software that runs inside many intelligent sensors and electronic controllers in our cars. Some of these controllers (or ECUs) help you accelerate, turn and brake. In addition their family members help lock doors, control windows and heat your seats while the big brats in the household (you know I mean car right!), play music, help you navigate and manage the ambience for you. That is why our software has to be light, efficient and most importantly reliable.

The actual way that a specific car behaves is governed by the team at the OEM(s) (like BMW, Daimler, Peugeot, Tesla or Volkswagen) who decide whether they are making a sports car or a station wagon. The designers’ success would depend on how they shape and structure their systems and components as well as how they want their “higher level”software to control the main systems in their car. The main systems are then in some cases made by the OEM(s) themselves, but more often than not, the systems come from suppliers. These Tier 1 suppliers who give their components or main systems to the OEM to integrate in the final cars, thus also have a lot of software that makes their devices do what the OEM wants the devices to do.

All of this controlling of devices and systems is done by the software that lives inside the little controllers (remember ECUs!) made by the Tier 1 suppliers. So “how the stuff works” or how the stuff “should work” is handled by the OEMs together with the Tier 1 suppliers (and sometimes other suppliers too) in the “higher level” software components which are called application components. Yes, “APPS”! Something like “APPS” or applications on your mobile phones that let you send texts, look at maps, or see if you are lost. This is also like applications or programs on a laptop that let you make presentations or type text into a webpage. So yes Tier 1 suppliers together with OEMs create applications that know how much fuel to pump into your engine or how much your electric motor should turn your wheels when you press the gas or accelerator pedal (“Power Pedal”, anyone?).

For these applications to talk reliably, safely and securely to the underlaying hardware that the applications are controlling, as well as to talk to each other they need to follow some rules and some commonly defined steps and guidelines. That is what we would imagine as being “below” the “higher level” software, to do all the work of making the application software’s wishes come true. A lot of folks call this the middleware and the firmware. Call it what you will, but it is a lot like imaging that the “APPS” are running on some kind of iOS, Android, Linux or Windows! Indeed it is and one of the components in this area is actually called the OS (Operating System).

So in order to not have everyone on the planet making a car, not end up reinventing the wheel, ... er ... not literally the wheels, but the way ECUs can work together, in a way that is repeatable, reusable and scalable there is a consortium or a group that explains how this middleware should work. This is called the AUTOSAR consortium. Rumour has it that even folks like TESLA, while reinventing almost everything in-house and doing a darn good job at that, sub-consciously follow or use many, if not most of the rules set up by AUTOSAR. So that means AUTOSAR describes the way this middleware work. The Operating System, the Communication (processes), Network, Memory Management and the Middleware-Kitchen-Sink all fit into this section known in Automotive jargon as the “AUTOSAR Stack”.

So every Tier 1 or OEM who is good at making brakes or maps doesn't have to spend time working on their underlying “AUTOSAR Stack” the same way every person who makes an app like “Facebook”, “Whatsapp” or “Mail” does not spend time fine tuning iOS, Android, Linux or Windows. In fact they would spend their investment money making better applications, optimising mechanics and improving designs instead of making operating systems (not referring to anyone right now! Just saying!).

Since the Automotive industry is cost sensitive, while also being safety and security aware, the hardware footprint (basically how powerful and how much memory the silicon or the “chip” has) available for each ECU changes based on the implementation and the use case. So the “one size” fits all of Linux and Windows for all PCs and Android/ iOS for all Mobiles does not really work well. (Actually I do not believe that it works that well in PCs and Mobiles, without good hardware-software integration, but I leave that debate for another time!). This means whether the OEMs and Tier 1s like it or not they have to make a compromise between reusability, customisation and optimum cost. So the middleware, available from well known stack vendors gets to be customised and set up. This is called configuration, after which all the software (yes including that Kitchen Sink) gets integrated.

This is where our “Ninjas” come in. We do not (necessarily) claim to know too much about playing music in the car (we do listen to music while driving and sometimes while working though!), how much the suspension should flex at a turn or how a Tier 1 should worry about temperatures in their devices. But we do know all about taking our friend’s AUTOSAR Stacks, and customising (the words are “configuring and integrating”, remember!) and optimising the heck out of the system to be useful, reliable, reusable and cost effective. As engineers the systems needs are also not entirely lost on us, we use our experience when our customers ask for it, also outside the main stack and stack requirements (“if” our customers ask for that).

You might ask - “What do you mean by optimising the heck out of a system?”. Well, sometimes our customers ask us to do a middleware assessment with our engineering heads looking at the system. If we knock off even a few cents to a Euro (or $, RNB, Yen, INR depending on what helps you buy your stuff), then by just helping our customer optimise their microcontroller ECU needs, over a few million cars that is worth a few million or more (cents makes sense)?

The other things that keep us busy are making sure all our customers can roll out features like over the air updates (yeah, mobiles phones have really ruined all of us, we just want everything to be downloadable, including our hair cut!), achieve our cybersecurity requirements (so that your neighbour does not use your car infotainment box as a video game) and remote diagnostics (so you don’t tell your service station that your air-conditioning system is wet after you crashed into a swimming pool!). While taking all that one step further we also are involved in a topic called Adaptive Autosar. This is much more like the Linux and the Windows that we know from PCs and Servers (in fact the jargon of Service Based and Client-Server Architecture extends here), but we have to make sure that if something fails you don’t have to press the brake, wiper and gear lever (Ctrl + Alt + Delete, anyone?) to get going or be safe. Instead we ensure that Automotive requirements and safety levels are ensured while you enjoy your driving, update your maps, change your charging profiles or have your car drive itself (if you prefer enjoying the view instead of enjoying your driving!).

It is about picking up challenges and finding solutions. It is about fixing stuff and driving innovation. It is about being relevant and also about defining the future. Just being a part of the future!