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.
Another year has come and gone and many eventful happenings took place in the history of DISTek. We may look back at 2015 as a turning point due to the substantial changes we made in all aspects of our business. Those end-of-the-year cards you get in the mail always seem to be bragging a little too much, but that is just what I am going to do because I think the year DISTek had is worth bragging about.