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.
In a world of complex systems, it may be easy to forget some of the basic concepts that build these systems. Software applications can consist of hundreds of individual files as part of one very large project. Those files all work together to achieve amazing functionality within an embedded system. There are instances where a project may include files written by teams located in different countries. We like to think that when this software is put into production all the bugs have been discovered and the software will work perfectly. Unfortunately, there always seems to be unintended use or a sequence of events that result in undesired functionality. Other times, there is just a plain old bug that managed to find its way into production software.
Commenting code is one topic, that until recently, I hadn’t known was such a widely debated issue in the programming world. It was something taught to me from day one in Computer Science at the University of Northern Iowa. Recently, my workplace posted a simple question on an open-discussion white board. “Should we comment our code?” The plethora of anonymous comments was certainly enough to pique my interest. According to the discussion, hardly anyone could agree on this question.
It certainly can be scary looking at a long bug list with a short deadline, but identifying and fixing software bugs can be manageable with a few strategies.
A second set of eyes.
Sometimes a very simple software error can be staring at us, but we miss it because we have been staring back so long. An example I faced was a section of code appeared to be setting a value used elsewhere in the code, but that value was never changing. When I finally had someone look at that code for me, the first question was “Isn’t that a pointer?”
Recently my team was given the opportunity to completely redo a particularly messy and troublesome piece of legacy C code, and as a team we decided to give MBSD a try. We had tried a few simple models before, all of which turned out to be more complicated than had we written the C code ourselves. But this time we were determined to do it right: we allocated plenty of time, received one-on-one training from the local MBSD guru, and reviewed the original requirements to ensure they met the needs of the system. Finally after exhausting all of the time, continually pestering the guru with questions and modifying the requirements several times, we succeeded in having a model based software design that actually worked the first time we tested it on the vehicle. It was a valuable experience overall and helped illustrate the drawbacks and benefits of MBSD over the typical C development.
The technical sessions seemed to highlight the NI Systems Engineering Group this year. The NI systems Engineering group is responsible for creating frameworks, reference designs and add-on LabVIEW toolkits. These packages are originally created for use within NI but are made available to outside developers as well.
This is the first in a series of posts by the folks that keep this place on track as a business – giving a non-engineer perspective on the culture of engineering.
Lost In Translation-The Bill Murray movie-That’s working with engineers.
I’ve come to the conclusion that my career has been headed down the wrong path for a long time. I know sales people who sell commodities, specialty products, medical devices, and they all tell me the same thing: It was easy once I learned my product. Well to heck with you guys, my product has no owner’s manual, has vacation days, and such a range of skills that I can’t simply say “That’s on page 38 of your product manual ma’am.”
Procuring software engineering services from a proven contract house has many benefits, which you already know if you’ve ever been cornered by one of their sales team members. As an engineer I know that there are always tradeoffs which must be made, and getting outside help on a project is no different. One possible way to maximize the value and effectiveness of contract software engineers is by the use of pair programming. Pair programming is an Agile software concept I was introduced to during my time working with a client, however it can be shoehorned easily into any development process. Pair programming simply means getting two engineers to sit together at the same workstation, often with two keyboards, to work together on a software solution. There are well documented benefits of increasing speed and learning while reducing mistakes and costs. In my experience, those benefits are compounded when using the services of a software contractor.
A while back I made an interesting personal discovery, and I want to share it with everyone in the hopes that it’s as useful to you as it is to me. Hi, my name is Ryan, and I like to develop software in my free time. Mostly, I like developing games.
It all started when I recently looked back over some of the work I did before I went to college. I was actually very impressed with my past work, too impressed. The games I developed before school were really putting my current work to shame. I started to think about why that might be. I figured I was busier now that I have marketable skills and, let’s be honest here, you can never play enough Dwarf Fortress.
