Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Successful Embedded Software Design
Jacob Beningo - Watch Now - Duration: 24:50
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.
10:43:47 From Enrico : is it possible to extend the qa ? the website was down for a good while, and still not enough time to listen to the whole thing in x2... 10:45:05 From Stephane : We will probably schedule another Q&A with Jacob later, either in the week or sometime next week. 10:45:14 From Gonzalo : Deliver on time is always a challenge. Do you have an advise on how to dimension the amount of work hours to get a job done in embedded programming? 10:45:37 From Enrico : Thanks Stephane! 10:50:36 From Leroy Monitor : Not directly related to you current talk, but I am a big fan of your efforts. RE Bandit Gangwere's talk on embedded CLI. I may have missed it but have not noticed this talked about in the few courses of yours that I've watched. Do you typically add CLI support to your apps? If so, do you have a favorite CLI implementation that might use? 10:54:58 From Gonzalo : Thank you for your answer 10:55:26 From Gonzalo : Agile is not easy to be applied directly on embedded systems when there is hardware development involved. What is a good way to organize a team to develop more than one embedded project simultaneously? 10:59:12 From Gonzalo : It sounds good. Thank you 11:00:40 From Leroy Monitor : Thanks Jacob 11:02:42 From Stephane To Jacob Beningo(privately) : Johan's talk is available now... 11:04:26 From Enrico : great question @ali 11:05:12 From ali joubir : thanks for the talk👏 11:05:23 From Leandro Pérez : Thanks Jacob 11:05:25 From Jay Cosper : thanks 11:05:54 From Leandro Pérez : Yes timeout isssue :(
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