This is the first post in a series that deal with delivering SEGGER products: how they’re designed, developed, tested, documented, and released.
This post is a general overview of some of the processes and organizational aspects in place at SEGGER and is background information. The second describes software design the SEGGER way and what benefits great product design brings to our customers. Following that, I explain how we ensure that the product meets our engineering expectations. And the final post deals with how we turn the software into a product by adding documentation and support materials.
Later posts deal with the nuts and bolts that make strong products, whereas this one sets the scene for potential customers that are unfamiliar with SEGGER, our products, our processes, and philosophies.
Why write these posts?
A website is a good place to get marketing information and product features, but there are always questions from customers wanting a little more information or a request to provide something vital to their purchasing decision. We had an enquiry recently in this vein, and it provided the inspiration to take to the keyboard and write so I (or the sales team) can simply direct prospects to a place where they can read about what we do and how we do it.
Customers, and potential customers, never get to see the day-to-day development processes and engineering that takes place inside SEGGER. As said above, I thought I’d take up the challenge and try to present some general information on how the products that I happen to be responsible for go through the development process at SEGGER, and describe the tools used internally to assure the quality of delivered products.
Everything described is based on solid engineering and a commitment to delivering robust, quality products.
With that said, let’s begin!
Why bother with quality?
Skip this if you understand why quality matters.
Dealing with potential and existing customers, in an engineering position, can be challenging. Without customers there would be no business, and engineers need to be mindful of the marketing and support burden associated with the products they develop.
Delivering non-functional buggy products to market reflects badly on the organization and almost guarantees that repeat business is off the table—word of mouth does the rest
Well-tested easy-to-use products are a joy, have a low support burden, and don’t tarnish the reputation of the vendor, they enhance it! This is what SEGGER wants to deliver. We want our products to be flawless and “simply work” because they are chosen by our customers who should focus all their energy on their code, building innovative products for their end customers.
We’re all agreed then? We start at the beginning with a plan…
The Quality Manual
The relevant parts of the Quality Manual relate to controlling our assets, the process of handling problem reports, estimating and tracking timescales, and the test procedures for release.
SEGGER is certified to ISO 9001:2015 and has a quality manual that defines what engineering must do, at a minimum, to deliver a product
We take it for granted that these procedures are respected by each engineer and product manager, so let’s move on to some specifics. If you are serious about product quality and customer support, ISO 9001 is simply a requirement.
You can find our certificate here.
The relevance of standards
More and more customers are very focused on only accepting software that conforms to MISRA or CERT C standards, is certified by some authority, or follows some other set of guidelines. I can understand why this is important for some customers, and SEGGER does undertake certification, but we also have a pragmatic view and our own coding standard. The document defines how a source file is structured, the documentation requirements for functions and other objects, naming conventions, and so on. A coding standard is a start, but SEGGER has more than mere mandates on code layout:
The SEGGER Developer’s Handbook defines how a product is structured such that acquired knowledge of one of SEGGER’s source code products is immediately transferable to any other SEGGER source code product
This simple design requirement means that any SEGGER engineer or customer will feel at home when easing into an unfamiliar SEGGER product. For engineers that must undertake some enhancement, the standard SEGGER design guidelines provide a framework to work within, a design pattern.
The Developer’s Handbook is the go-to reference for existing SEGGER developers and new recruits and is a living document, updated as necessary, as we continue to expand our product portfolio.
MISRA
One of the things that I would like to clarify is that achieving MISRA compliance does not provide an absolute assurance of quality.
Any piece of crufty bug-ridden code can be MISRA-conforming and yet remain a crufty bug-ridden piece of code no matter how much MISRA lipstick you slap on it
Quality comes from clear concepts, great software design, and source code written by an experienced engineer that is entirely straightforward to put to use by a customer. I find it quite astonishing that a decision on software can be made only on MISRA compliance rather than taking a rounded view of the quality of the source code and design, the documentation, the development process, the supporting materials, and the stability and reputation of the organization behind the product.
Source code quality
SEGGER source code products are licensed worldwide to small, medium, and multinational companies. The quality of the product is essential, in terms of performance and runtime footprint, source code readability and design, documentation accuracy, and the competence and efficiency of product support.
SEGGER source code is peer-reviewed and passes through more than one commercial static analysis tool to reveal potential problems
As explained later, it’s also run through multiple compilers in different ways to reveal any compiler-related or portability issues.
But back to those static analysis tools. In fact, our software has revealed issues in all the static analyzers we use to test our software, from simple false positives to plain errors, through complete analyzer failures. Even the vendors that vend “quality enforcement” tools have an issue with the quality of their expensive quality-analyzing products, which is something to dwell on.
The same can be said for compilers: we have instances where compilers give up compiling SEGGER software, throwing an “internal compiler error” or (worse) simply generating incorrect code. Although we have straightforward non-tricksy code, we organize our code as best we can such that it does not trigger these events. But even well-respected tool vendors continue to have problems in compiler reliability at high optimization levels, possibly because they are forever chasing better code generation.
Independent certification of our products
It’s always good to have independent validation of your products: it’s confirmation that what is delivered conforms to industry standards and customer expectations.
SEGGER has a safety-certified RTOS, certified cryptographic algorithms, and certified drivers
embOS-Safe gained certification for functional safety use and conforms to MISRA standards. Without test suites, continuous and thorough testing, and excellent documentation, pushing a product to this level is impossible.
In the same way, emCrypt’s algorithms have been submitted to NIST and certified on real silicon because we have taken the time and borne the cost to go through this process. (Spoiler: this type of testing is described later in this series.) This makes us confident in the algorithms that we deliver, and is independent validation of our products so customers too can be confident in the correctness of the products we deliver.
For developers wrestling with developing USB devices, a particularly unforgiving task, emUSB-Device has Windows Certified drivers and SEGGER can certify your specific driver.
Next time…
My next blog post will describe the way that SEGGER products are designed and the benefits that our design brings to developers.
Bootnote
I happened to be working on ECU software as a contractor at Rover Group when one of Rover’s engineers started to develop the first set of MISRA guidelines along with other industry members. At that time the engine management code was written in 80196 assembly language by a team of engineers. Each code fragment was augmented by interface definitions as comments, and interfaces and actions were validated by software tools I constructed as a side project before final, formal methods validation by an external laboratory. So, yes, I am well acquainted with software process, reliability and, crucially, liability for the software that some engineers must write and why standards such as MISRA, and associated validation tools, exist.