Close Hardware and Software Integration

From knowing where you are going, lower overall development cost, to getting your hands dirty!

We have been passionately pleading about how the best performance and often the best overall development cost can be derived from an approach that enables close hardware and software integration.

The point regarding performance is of course a no brainer. It is like saying, the gem of a guy, Usain Bolt, is obviously super fast on a track, leading to the conclusion that he is probably good at running short quick sprints on almost any track. That does not mean he can't long jump and probably play basketball better than most of the world's human population. He most probably can! Would he be the best in the world at basketball? There would surely be basketball players better than him at playing basketball! Ok! That was a very vague example, but like I said this first part needs no explanation.

The part that close hardware and software integration can also work hand in hand with managing overall development cost is less direct.

• In fact this scaling and correlation works better when the number of variants and products increase. (who did not see that coming, huh!?)
• This is also where design, architecture, planning and systematic development are essential. It is all about sharpening your axe for 90 minutes so that you can cut in 10 minutes rather than spending the whole day fighting with and against your axe.
• It is about choosing your hardware wisely so that you can continuously build and scale your software precisely in tune with the hardware or hardware-family and with your target end applications.

The company that best personified this idea (among many others, but the one that catches a lot of media attention, and maybe makes fantastic products too), is APPLE (Apple Inc.). The idea of close hardware and software integration was no more apparent and relevant in the latest WWDC by APPLE two days ago. They also explicitly mention this several times that part of their product performance differentiation is this close HW-SW integration. Yes, Apple products are at a high price premium, but that quality to price ratio is not related to how you plan your hardware and software, and I will not jump into that debate now. Yes, if you made your hardware and software in close coordination with each other for an iPhone then surely the iPhone experience will be smooth, fast and fluid. Then if you did the same with an iPad then that too on it's own would function great. And the watch... And the Apple tv... And so on! But the point is all of these individual products were not actually completely different, islanded and separated devices with siloed architecture needs.

This brings us to why the BIG announcement of Apple Silicon for Macs (their computer lineup), is such a huge announcement. (In my view, while everyone knew it was eventually coming, after Ax chips appeared in the smaller devices, the announcement is actually a major underestimated differentiator going forward). By planning ahead, this shared Silicon-family approach will help setup the hardware (from the silicon upwards) in a step-wise fashion so that the software can be also developed in a similar step-wise fashion. Each step can then be aligned to a product, product-family or variant that has to be developed.

Once we realise this family based silicon and hardware approach it is easy to understand that the logical implementation of this strategy will enable systematic reuse of components and most importantly of software. Basically, simpler (and generic) functionality can be implemented across the entire family and the higher and more complex functionality needs to be addressed and managed separately only for the higher models.

What you get, is the opportunity to develop and maintain modular scalable software along with your specific hardware that it can be closely tied into. The main point is once you make it modular and scalable the ability to manage it becomes easier.

This means that organisations can spend less time on endless meetings and less money on Excel-Sheet Jockeys who today masquerade as managers! When you have this scalable and fundamentally logical approach it means you also need less effort in defining frameworks to make new modules backwards compatible to a hardware or system that is no longer state of the art (or rather simply just does not have to be on your roadmap). Your process of abstraction also would become simpler. Most of all you can define your Design Patterns for critical topics like memory mapping and how you manage your IO. (For more about Design Patterns just look at my previous posts)

Beyond development costs and better management, there is another fundamental reason to focus on hardware and software integration. I remember the old jokes about General Motors teasing Microsoft, back in the day, about how a PC crashing might just irritate you but a Car crashing can cost lives. This is actually no joke for the Automotive, Aeronautics and Space industries. Here the topic of Functional Safety (FuSa/ FuSi; if you prefer "Functional Sicherheit") becomes much more relevant.

This is really not a process where you can hack away until your code works somehow and then you backfill documentation to pretend that it works well in all your possible risky scenarios. I am not saying this latter approach is (unofficially, while ignoring relevant development processes) not possible, it would just take way too much time and increase the risk that you might overlook something during a necessary and lengthly testing process. The simpler way is to actually follow the logical and systematic approach to developing your systems - in terms of both hardware and software. I will later write in detail about Occam's razor, but here too, we should not overcomplicate our processes. By ensuring that your software is tailored to your hardware (and when possible, like for people like Apple Inc., tailoring their hardware with software, right up from the silicon), you leave less to chance in terms of having something sitting in your software, that was not intended or planned for a particular flavour of hardware. Something that can cause frightful failures when you least expect it.

For us in the Automotive space, some people might complain that they cannot tailor their software every time or muscle their way to getting custom hardware. Actually there is no need to muscle your way in, or to complain about it when you can't. The approach on the hardware side would be to judiciously choose a good silicon family (family of micros with scalability in terms of footprint and power), from a reliable and cost effective semiconductor vendor and check the following:

• Does the little kid in the family have resources and compute power for the simple projects?
• Does the big brother in the family have the strength - performance, cores, memory, etc for the complex and safety critical projects?
• Is the silicon architecture really aligned within the family (like for memory mapping, pin mapping in a sequential and logical way)?
• Does it work well with the peripherals that you need in your different products and product lines?
• Does it have the normal Automotive needs already in terms of "MCALS" (abstraction software), compilers, ease of debugging, etc?

Then you can build your reusable and scalable architecture by planning your boards (PCBs with all your peripherals and sensors) around this family of micros, followed by your software development with a simple SDK concept based on AUTOSAR.

Over the last weeks a couple of engineers asked me about how they can actually get a better handle over this way of thinking. Within RealThingks Automotive (and IOT), we make a major fuss about our folks really being hands on with actual systems (small or big). During a demo last week, I asked one of my bright colleagues what she learnt from a small proof of concept hardware-with-software development project that she worked on. She mentioned that her experience was awesome, starting from debugging the hardware, getting simple stuff off accelerometers and the sensors that exist in the real world, to actually implementing TüV level functional safety requirements in the real world. This incidentally translated into hands on support in another time-critical project. Just running a configuration tool is much like playing a video game, but getting your hardware and software to do exactly what you want it to do, is engineering! So for those folks who are not within our RealThingks Family, and are not already hands on with hardware (and are not really connected to the real world, other than via Amazon and Flipkart), I would recommend getting your hands on the following:

• A Raspberry Pi (helps you make the first step from a big computer to a tiny one, being easy enough for even me to make my way around it, straight out of the box)
• Arduino IDE (just download it)
• An arduino device or an ESP32 (like in this simple video from the guy with a Swiss accent!)
• Some Free Time! (to watch the YouTube videos and to fiddle around)

Once you have the time and the toys, then... Happy Hacking! Because with your ESP32 and Pi you can play around before you need to worry about FUSA/ FUSI, while you really get your hands dirty.

For those of you on Automotive (or TüV certified IOT) projects, just don't hack, but enjoy engineering the heck out of it! ...Or as Mark Watney (Matt Damon) said in The Martian - "So, in the face of overwhelming odds, I’m left with only one option: I’m going to have to science the **** out of this."

Which is more theoretical, and I would have preferred if he said "engineer" instead, which is more practical at getting results.

Do it because you want to... People!