In June of this year I had the opportunity to attend our DISTek-led Modeling and Simulation training course. Currently, I am the lead of the Automation and Test group here at DISTek, but in my previous roles I have been heavily involved in desktop application development, as well as test system development primarily using LabVIEW. My exposure to modeling and embedded has been somewhat limited thus far, so I thought it would be a good experience to learn some of the basics.
Have you ever played the game “telephone”? It’s where you have a line of people and starting on one end someone whispers something into someone's ear. That message is then passed on to the next person and so on and so on. Once it reaches the final person, you may find out that the message was misinterpreted. “Big dog” may have changed to “bed bug”. This is one of the major problems that have plagued software design and something I see on a regular basis. Engineers receive requirements that were already passed down through other people, so the engineer is left to interpret them the best they can.
Engineers working in the off-highway vehicle equipment industry, particularly with electronics.
This training is designed as an introduction into MBSD, specifically around the toolboxes MATLAB, Simulink, and Stateflow. To start, this class is meant to be an alternative to the 5 day training class that the Mathworks offers. The class will be run leaner with a greater focus on MBSD. DISTek will be incorporating feedback from attendees to make sure there are no significant gaps. The goal of this class is to provide a basic introduction to Simulink and Stateflow block sets, applying them to implement basic features. The class will be hands on with demos and examples throughout, ending with more specific in-depth exercises. Best practices and MAAB guidelines will be employed throughout the training.
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.
In college, I had a physics class called Modeling and Simulation of Physics Systems in which students wrote code to model the physical behavior of various systems. The final project of the class involved choosing a system of interest, developing a model for it, and presenting the results with some sensatory aid.
Somehow I happened to fall into the last slot of the year for the DISTek blog. I am not complaining as it gave me a few more days to prepare. Obviously we still have a few more days left in the year (3.6% of the year as I write this), but by and large the business part of the year is grinding to a halt. As the Scrum gurus would tell us, we should have a retrospective from time to time, so here is mine for the year.
Bumper crops are great … except when they are not. In general, the corn belt had superb weather this growing season. That led to record yields at a nationwide level and that massive supply, amongst other factors, led to sharply reduced prices. Corn was over $8/bushel in 2012 and is now below $4/bushel. A similar story played out in wheat and soybeans as well. I know there are some relevant terms from my past economics classes like price elasticity of demand, but there are plenty of opinions on this topic and I will leave it to the reader to peruse those as desired.
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.Read full blog post here...
Recently I was provided the opportunity to work with someone who utilized Simulink to create plant models for our customer. My experience and knowledge about Simulink and modeling was non-existent. I have heard of Simulink and seen some models, but for the most part, I am Simulink illiterate. This made my initial conversations with my co-worker an endless session of learning. It was all new to me. Add into the equation that his goal was to create a plant model; I was even more overwhelmed – seemed like I was drinking from a fire hose.