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.
AUTOSAR, or AUTomotive Open System Architecture, is a standard to commonize automotive control systems across the industry. The benefit of running an AUTOSAR standard operating system across all electronic control units (ECUs) within a vehicle platform, or a company/industry, is analogous to the benefits of all PCs within an organization running a common operating system. This allows the application engineer to develop software for the standard operating system and gives the organization a single solution, which is independent of hardware variations. In addition....
How does application software pass data within an AUTOSAR-compliant system? The answer depends on what the application wants to communicate with. There are two main methods of communication for AUTOSAR-compliant application software: sender-receiver communication and client-server communication. Let’s begin by discussing application software in AUTOSAR before diving into communication.
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.
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.