Home > On-Demand Archives > Talks >
Successful Embedded Software Design
Jacob Beningo - Watch Now - Duration: 51:46
The modern embedded software team has a lot of challenges to overcome to successfully deliver software. Today’s systems are complex and require a careful balance between the software architecture design, development processes, and implementation. Failure to do so results in embedded software projects that are delivered late, over budget, and buggy.
In this session, we will explore modern firmware development techniques and processes that will help you improve how you design, build, and deploy your embedded software.
Topics covered in this session include:
- How to define your embedded software design philosophy
- The software architecture design process
- Software domains
- Application Modeling
- Introduction to the modern embedded software build processes
- The build process
- CI/CD for Embedded Engineers
- Tips and tricks for successful implementation
- Getting process buy-in at all business levels
Attendees will learn critical concepts and processes that they can immediately apply to their own development cycles. Attendees will also see examples on modern build system set ups, CI/CD, and more.
Thanks for the comment. I definitely agree this is an important area. I have a colleague who has a great comment on this in that it's "Managing customer expectations", something that has to be done up front, but also done throughout the entire development cycle.
Excellent presentation, thank you.
Thanks!
I really liked your task code generator as a way of creating consistent code.
I recently read the book Righting Software which talked about how to design the project itself as well as decomposing based on volatility instead of the usual functional decomposition. The claims made are that this ensures on-time delivery and the ability to adapt to change much more easily. I wonder if you have come across this approach and if you think it would make a big improvement to how we tend to work in the embedded world?
Thanks for the comment.
I’ve not read about the approach in Righting Software. I’ll add it to my reading list. I think with any approach, it doesn’t hurt to run a small test project with it to see how the results turn out. So far in my career, I’ve heard about many silver bullets to ensure on-time delivery, but the human factor seems to generally always get in the way.
I’ll look forward to reading about this other approach.
From your experience, does the stage of the system influence any of the architecture design considerations or implementation techniques? For example, if the system is a one-off prototype, versus being commercialized, versus already having 10,000+ units in the field? See you at the Live Q&A!
I've found that in general the architecture of the system evolves over time. At first, you design architecture A that we belive solves the problem. We start to write code and discover that the architecture isn't quite right because of several unknowns. We feed that knowledge back into the architecture and evolve it to handle the new discoveries. Generally, an architecture starts to get stable as it reaches production. However, you do want to make sure the architecture is flexible because as new features are added and maintenance is performed, the second law of thermodynamics applies and the architecture and become chaos if developers are careful.
With continuous integration, are there setups that actually involve the hardware, or is it all simulation based? If hardware is there, how does redundancy get added to the setup, and is it necessary? For example, if that one piece of hardware used for the continuous integration testing is not calibrated properly or has a bug.
There can definitely be HIL in the pipeline. The big question then becomes how much is necessary. With all these processes it's easy to try and build the perfect CI/CD pipeline that ends up being overkill. The best thing to do is start simple and small and then build on the capability. If something can fail like a calibration, actuator, etc, try to have some test that can detect if the set up and system is good to go. If not, have the pipeline fail to get the attention of the dev team.
With the current chip shortage situation, we are seeing more and more migration projects where our customers ask us to migrate their firmware to a new microcontrollers. Do you have any advice on how to approach these type of projects ?
Yes definitely. I've been guiding a lot of companies through this process over the last 12 months. A few short answers to things to consider when migrating:
1) Carefully examine the software architecture. Hopefully, it was layered, but most likely it's tightly coupled to the hardware. You'll need to account for time to refactor the architecture to decouple the application from the hardware. Adding in an abstraction layer is a good idea if it does not already exist.
2) Porting code is always dangerous in that something is going to break. I like to move code over in small chunks along with their unit and integration tests. If the tests don't exist, it's the perfect time to add them. That way when you move the code over, you can detect if you've broken something.
3) In a lot of these projects, I'm expecting to see customers switch MCU's again in the next 18 - 24 months. As everyone changes, it's like moving from one side of the boat to the other. Eventually the suppliers with parts are going to have so much demand that they have supply chain issues too. Make sure there is flexibility to move back or to yet other parts if needed.
Well, I have to apologize in that my talk ran a little long. It?s ~50 minutes. If you are interested in attending the live Q&A, which will start 40 minutes in from the session release, you?ll need to watch the talk at 1.25x, or come back and watch the last 10 minutes as time allows.
Also feel free to put any questions you may have in the forum here. I?m happy to answer them.
Thank you Jacob for this talk, which I found realy useful.
I agree with your 7 principles to produce successful software! I would just add an extra one: pay a special attention to the requirement gathering phase. Before the coding phase can be started, requirements for the current work pakage / user story shall be clear, complete, understood and agreeded by all stakeholders.
Neglecting this work because "requirements always change" and / or "requirement gathering is just documentation, and we do not have time / code can document itself" always lead to time loss or disaster on next phases