Software Architecture is a key component in developing a long term, successful embedded system device. However, the topic of what is included in software architecture is complex. Let’s take a look at an example of what software architecture is with an excerpt from Luke Hohmann in Beyond Software Architecture: Creating and Sustaining Winning Solutions:
“Software architecture is the sum of the nontrivial modules, processes, and data of the system, their structure and exact relationships to each other, how they can be and are expected to be extended and modified, and on which technologies they depend, from which one can deduce the exact capabilities and flexibilities of the system and from which one can form a plan for the implementation or modification of the system.”
Safety is a challenging status to achieve and maintain, thus the need for the guidelines that collectively fall under the heading of Functional Safety (FS). DISTek has always been conscience of safety as it applies to the products developed for our customers. This includes implementing the various requirements and guidelines associated with Functional Safety, as expressed in documents, such as ISO 25119.
Every software engineer knows there are strengths and weaknesses to every programming language/architecture. Trade offs must be made to improve certain aspects of the system. AUTOSAR is no different. The key is finding the right tool for the job by determining which aspects you need more of and which you don’t. During my time working with AUTOSAR, I’ve found some aspects that AUTOSAR does well and some that it doesn't. I’ll start with a brief overview of what AUTOSAR is and then jump into the nitty-gritty.
Here at DISTek we just competed our 24th full calendar year as a company, which means our 25th anniversary happens in 2017. We are excited to think about our future as we pass this milestone, but it is also healthy to step back and review what we did in 2016. We took some bumps and bruises along the way – as did many in the industries we serve – but we also had some exciting successes.
As promised, here's my Part Two blog posting regarding the raspberrry pi.
The default kernel in Raspbian Jesse, the latest release of the raspberry pi’s official OS, could use a tune-up before being fit for duty running time-sensitive machine controls. On a vanilla Linux kernel program, latencies depend on everything running on the system making consistent and punctual tasks difficult to guarantee. The RT PREEMPT patch is a popular fix for this problem. The patch converts Linux into a fully preempt-able RTOS. If you want to control physical processes with your pi, as I intend to in DISTek’s training curriculum update, this is the way to go. But how big of a difference does it make on a pi?
Recently, I’ve been launching a little office project to develop a new training curriculum for DISTek engineers. Because it is hands-on training, it will require a toolchain. Since our customers use everything from off-the-shelf professional solutions to home-brewed ones, it’s important to prevent the nuances of a new toolchain from being a distraction in the training’s purpose of conveying good software practices and controls concepts.
I recently graduated from Iowa State University and began my career at DISTek, and during that time there is one thing that I notice engineers hate doing: documentation. Despite being loathed, it's widely believed documentation is one of the most important things in software development. I always strive to see that code my teams and I have worked on will be well documented in some form or another. I, especially, run into problems with code that is developed as a library (a set of functions and data structures).
If you’re a regular reader of this blog, then you probably know a lot of about the areas that DISTek works within. Our expertise ranges across the off-highway vehicle industry (including agriculture, construction, and forestry) with engineers that specialize in a variety of disciplines. Out of convenience, we typically group these disciplines into three big areas (“embedded software”, “automation and test”, and “modeling and simulation”), but the reality is that we do all kinds of projects that cross-over between these disciplines.