When creating an application, one of the most difficult aspects is choosing a language/framework that will meet all requirements. The VT Anywhere team has learned this first hand, hence the title of the application VT Anywhere. VT Anywhere is split into two parts: User interface and Server. The languages of choice are JavaScript and Rust respectively.
There are tons of tutorials out there that show how to use Git, starting with easy things like cloning a repository and committing locally, then pushing your commit to the server. There are lots of sites and videos that will help you achieve a competent level of Git expertise – like this one. However, you may struggle with the interface and if you have problems, you may struggle to understand why and how to fix them. That is why I am going to explain Git this way: inside out, backwards and hard. This three part series is targeted for people who want to excel at using Git and deeply understand it. This is also intended for people who are willing to persevere a bit more than the average person. Lastly, this is for people who like to see the beauty in things and, trust me, Git is beautiful.
Between company shutdowns and working from home over the last few weeks, some organizations are slowing production and running into various struggles to keep moving forward. For DISTek’s VT Anywhere team, we have been getting even more done now than ever before. While Slack calls and meetings have completely replaced in person interactions, the team has remained focused and very productive.
Eliciting a set of user stories can be a challenge when stakeholders are not sure where to begin their description of the solution they require. It is often up to Requirements Engineer (RE) to guide the stakeholders along in assessing the problem in need of a solution, as well as assessing the best solution for the problem. The RE must further help the stakeholders partition the solution’s description into manageable tasks, and express those tasks as User Stories. Workflow Driven Elicitation (WDE) is a systematic approach that helps achieve all of the above.
In my personal projects, I often work with various sensors which require digital data verification. One such sensor required the use of a Cyclic Redundancy Check (CRC) to verify that the information that the micro-controller read from the sensor was being received correctly. A CRC is a method for calculating a checksum from an array of data. The software examples that I was able to find to develop my understanding of implementing a CRC were poorly documented. Moreover, these examples were often so optimized that the underlying behavior was not immediately recognizable. Many examples simply used a lookup table—which provided no satisfaction for my “what-makes-it-tick?” personality.
Hardware in the Loop (HiL) systems are used in the development and test of real-time embedded systems often found in Electronic Control Units (ECU) within almost any on- or off-highway vehicle today. HiL systems are comprised of both hardware and software that can simulate the larger entity (i.e. car, tractor, etc.), so that the smaller ECU can be inserted into that larger system to determine whether or not it’s internal real-time embedded system is performing as intended. While this may seem like a mountainous task for vehicle manufacturers in industry today, DISTek has invested in tackling the design and production of an internal HiL solution.
Here at the DISTek products department, we’re always looking for ways to make our user’s lives easier. As engineers that use our own products, this is doubly important to us! We’ve identified that open source tools can be one possible solution to alleviate potential issues down the road.
We spend a lot of time designing user interfaces for ISOBUS VT clients. There are a few tools currently on the market, and while these tools get the job done, we’ve found a few shortcomings…
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.
Much of the software engineering industry uses testing techniques that aren’t often available to those of us in the embedded industry. In my experience, this has definitely been true of automated UI testing while working on ISOBUS VT clients. In a previous position, I spent much of my time creating test frameworks, including those for testing web applications through the UI.
Regular DISTek blog readers will have noticed that we took a VT server implementation to AEF PlugFest in spring 2017. Part of our motivation from the start of this project has been to give VT client developers the ability to automate functional testing of their applications.
Acquiring and/or logging high speed data, using the traditional DAQmx scaling approach, will consume considerable amounts of memory due to its use of the double precision data type. Each sample collected will consume eight bytes of memory whether being stored in memory or on disk. This size is fine when collecting data at lower rates, but if you are collecting data at a rate of 1 MS/s, eight bytes per sample is too much for most systems to handle.
A customer has been receiving field failures and the root cause has been difficult to determine. They have ideas of what may be causing these failures and need a test system that can simulate the various conditions and monitor the Device Under Test (DUT) to assist in determining the root cause. The customer turned to DISTek to provide a bench-top setup that will control the DUT and measure multiple in-circuit test points for events that may be damaging field effect transistors (FET) along with recording FET case temperatures. Custom events have been defined by the customer and will trigger the system to capture pre and post-trigger data. The test system should also provide various loads to the output of the DUT.
