One of the main benefits our customers derive from embedding a Critical Link System on Module (SoM) in their application is speeding up time to market. We’ve been told by some of you that the estimated time savings can be up to 9 months over what would be involved with a ground-up development process. While we’re accelerating project completion for our customers, we’re also developing products of our own. So we’re always on the lookout for ideas that will help us speed up our own development cycle.
Given this, I was interested in a recent article on embedded.com in which a group of Intel engineers lay out their ideas for “Using system engineering techniques to accelerate your next project.”
While the article – which is by Matthew Torgerson, Paul Durazo, Todd Langley, and Vira Ragavassamy – specifically references the automotive industry, the concepts they raise can, and are applied generally. Because the article is on embedded.com, there’s obviously a focus on embedded systems, which caught my attention. But I was also looking to see whether the authors take a different slant on systems engineering (SE) than we do at Critical Link. They don’t, which is not surprising, as the principles of SE are fairly well known, and they’re principals that we’ve been putting in to practice for years. In fact, our approach with SE is to some degree what distinguishes us from other design services companies.
SE approaches can be applied to embedded systems, since these embedded systems are systems within systems, and “are now reaching the complexity of [the] larger systems” for which SE has generally been used. Today’s embedded systems – like our SoMs – are a subsystem within an overall system. The tools that SE offers can be used “to carefully define subsystems, interfaces and overall integration.”
The authors contrast their suggested SE approach with a waterfall design approach (that we’ve used many times in many of our past lives in the aerospace industry), which the authors believe takes too long by today’s rapid development standards. (They attribute this to “excessive debug iterations.”)
They then lay out the more “holistic” V-Model approach that SE offers, which they categorize as one based on:
- Crisp product usage definition
- Rigorous requirements analysis
- System architecture and subsystem definition
- Incorporating cross‐functional and stakeholder feedback throughout the process
A lot of attention is focused on the importance of that “crisp product usage definition” stage, and you won’t get any argument here about the importance of having detailed and well-thought out definition of what a product is going to be used for. We spend a lot of time with our customers making sure we have this understanding. This lets us determine which SoM variation will provide the best fit from the outset, and require the fewest back-and-forths.
Also, when we’re involved in a more central role in a customer’s product development, we apply our system engineering skills and techniques to make sure that we are on track to build precisely the product that the customer is looking for, and that at the end, the product performs to these expectations (through verification).
As we all know, time to market is getting increasingly more important. The more leisurely and forgiving development cycles of the past are just that: a thing of the past. The system engineering approach described in the article isn’t really any big revelation, but it’s what we’ve learned long ago as the “right” process to develop the product that the customer has envisioned for their company.