SME Interview: ALM Tools for ISO 26262 Compliance

-An Interview with Adam Saenz and Nathan Haynes From LHP Engineering Solutions

I recently had the privilege of interviewing Nathan Haynes and Adam Saenz - both subject matter experts on ALM tools and well respected engineers. In this episode, we bring you the latest insights around ALM Tools for ISO 26262 compliance.

Watch the full interview or read our transcript below, I hope you find this information helpful!

ALM Tools for ISO 26262 Compliance

Marty Muse: Hi everybody. Marty Muse here. VP of Marketing at LHP. I'm really excited today to be sitting with Nathan Haynes. Nathan is a senior software applications engineer at LHP. Nathan, how many years have you been with the company?

Nathan Haynes: Let's see, I started in 2014, so a little over six, almost coming up on seven here in February, I think.

Marty Muse: Great, great. And we're also sitting here today with Adam Saenz, a principle embedded controls engineer. And, Adam, how long have you been with LHP?

Adam Saenz: About two and a half years

Marty Muse: OK, great, great. Well, I appreciate your time. We're here today to talk about application lifecycle management (ALM).

So, let me just open up here at the beginning and ask or pose the question, you know, what exactly is ALM and how does it pertain to functional safety?

Nathan Haynes: So, ALM you know, obviously, it stands for application lifecycle management. You know, and ALM is really the, it's kind of the tools and the process that basically manage an application, or, you know, any kind of software or product, from the beginning of its life, all the way to the end of its life. So, basically, you know, when, from the very beginning planning stages all the way to the end of its actual lifecycle, in terms of how it relates to functional safety, it's basically, you know, functional safety requires a defined process, requires traceability, for its implementation. You know? And that's going to be difficult to do without some kind of ALM system. You know, that’s not necessarily to say that it's impossible to implement a true functional safety process without ALM. But it's going to be very difficult to do it without it, so it's just, it's basically a way to make that flow a lot better and to give you an actual solidified process around it.

Marty Muse: Okay, great, so with that said, the definition now understood, what exactly is driving the need for ALM tools?

Nathan Haynes: So, I think there's a couple of different factors, especially in the automotive industry. So, there's two things right now that are really, well, really three things. But the two of the biggest ones right now are going to be ASPICE and ISO 26262.These are going to be the two biggest ones, probably the third one being cybersecurity. So most automotive companies right now are either aware that they need to move towards these things, or they're already in the process of implementing them. So, I think, you know, most of them are putting into place an ALM system to help them manage the process. You know? So, you know, kind of like I said before, you know, without an ALM system, it's going to be hard to achieve these processes in any kind of certifiable means. So, I think, you know, the biggest thing is going to be those two standards coming down and really, you know, the third standard being cybersecurity.

Marty Muse: I guess the question I have next then, Nathan Haynes, if you don't mind, is to take the next question: As well as with that said, how does an organization decide on what tools they're going to use for ALM?

Nathan Haynes: OK, so there's a lot of different factors that are going to go into it. Probably the biggest, I would say, would be the size of the organization. So, a big multinational organization is going to have different needs than a small startup organization. They're both going to require an ALM system if they're going towards either ASPICE or ISO 26262. The capabilities that they need and the expense of the tool are probably going to be two of the biggest factors. The larger multinational corporations are going to have the big infrastructure and the IT organization that can roll out big internally-hosted ALM systems, things like, IBM DOORS, or PTC Integrity, or some of those type of systems. 

Now, maybe a smaller corporation, that has smaller development teams, and has a smaller IT staff, might look at other platforms that are out there that are more of a software as a service type tool where they don't necessarily have to host it internally. But it gives them the same features or many of the same features and capabilities that some of the larger systems offer, at a smaller cost. And, they don't have to deal with the infrastructure. Some of the other things that they are probably going to be looking at are, what type of APIs are available for tool connectivity. 

So, if they're wanting to connect their tool chain to other tools to build out a set process, they're going to have to take a look at what type of connectivity is available. Some have more robust connectivity than others, so I think those are probably the biggest factors that most companies are going to be looking at. 

Marty Muse: Okay, great, appreciate that. Adam, let me bring you in here, as Nathan Haynes mentioned a few minutes ago this idea of traceability. So, I guess the question I have right up front, if you don't mind, following along here is: What does traceability really mean, and how does a company achieve traceability as it relates to, you know, verification for the ISO 26262 compliance? 

Adam Saenz: Right, so yes, all of these safety- and very process-oriented standards is that, that's a big thing, is traceability, and the reason for it is that’s how you show proof that you've done your due diligence and developing in cycle to safety, and if it's a general functionality. And so, that traceability starts with your high level functional requirements, and all the way, all the way down the line, and you start going into lower and lower level requirements, all the way through test cases to verify those requirements, and then to the results. So that you can show proof that you developed your product and you've done various work and revisions to enhance it and show that it's complete and correct. And then once those requirements are complete to test, that they actually were implemented. 

So, yeah. That traceability has to happen all the way. Not only on the design side, but on the verification side. And the result, of course. Not only check the requirements, but the results need to be checked.

Marty Muse: Along those lines, what can we do to increase productivity, reduce verification time and eliminate the risk of human error? 

Adam Saenz: Yeah, right. So, so that it becomes a key, and these processes help us to meet our objectives, such as ensuring safety, but they don't come completely free, there is an additional overhead of having this level of formality. 

So, one way you could do this, as we've been talking about, is the use of tools. Leverage the capabilities of your tool, and that helps you just kind of naturally maintain traceability as an example. 

Now, using multiple tools, different tools have different strengths. As you cross over from one to the other, you start identifying possible pain points. So, you need data from one to go to the other. And the last thing you want to do is have duplication of data if it's at all possible. But, you know, in some cases, it just makes the tool easier to you that there's duplication. 

So, you need to have some kind of method to ensure you have cohesiveness between the tools. So, it is really where tool integration comes in and try to automate maybe that process. And that's one way we can remove human error, so we look, as we get data from one to the other. 

Marty Muse: OK, great. Then lastly, just to wrap this up, what does LHP do, or what can we do, to actually help companies with their tool integration bridge the gap? 

Adam Saenz: Yeah, so we have a lot of engineers that have suffered through this and in various forms and even other industries. So, what we've done is leverage kind of our lessons learned from those experiences, and we can and we will go through and look at good use of the tools. 

And then when you have that crossover point of transferring data from one tool to the other, how can we make that a little more efficient? How can we get the tools to work together? 

So, we have actually worked on various demonstrations of tool integration to show that just to help simplify the life, other than engineered and designed. As an example, we have a project going on, what we call ALM driven test, and in this case, we've taken the traceability. We're going from requirements to actual test cases, and we create a test case in the format, that, we have a tool that will go out and pull data from that test case, and then pass it over to the automated test environment. So, that happens seamlessly. 

And that just enhances that, removes the time and the chance of error from copying data over from the ALM Tool test case over to the actual execution procedure. So, we tried to remove that aspect of it. Just clean it up a little bit and prevent someone from making them a thing because that's one thing as humans we have found. It ends up being kind of a mundane task, and that is where you start losing focus, and that's not really on the critical things where you have to pay attention. 

Marty Muse: Great. Again, great having you guys join us today. Appreciate Nathan Haynes and Adam, both joining us. If anyone is interested in LHP and our ALM Tool integration services and how we might be able to help you develop in a safer, faster environment, please reach out to us. You can contact us at LHPES.com. Or you can email us at sales@lhpes.com. And for those of you who have not checked this out yet on the website, please do so. 

Appreciate all your feedback, and we hope that everyone who has watched these videos today, or this video today, has found some value in it. 

Thank you!

Interested in Learning More About ALM for Your Organization? Contact Our Team Today! 

Interviewee: Adam Saenz

Adam joined LHP in 2018 bringing over 15 years of engineering experience in many areas of product lifecycle development. He specializes in embedded system design and has held positions as a software engineer, electrical engineer and systems engineer. As a software engineer, he has worked on control algorithm development and device driver level software. His hardware experience includes analog and digital circuit design, PCB layout, and FPGA firmware development. His system engineering experience includes developing architectures, writing requirements, and test case/procedure development and execution. Over the years, Adam has gained extensive experience in board bring up, hardware/software integration, and troubleshooting at the PCB, system and system-of-systems levels. He utilizes his experience in both hardware and software to determine the root causes of problems and apply the appropriate solution at the right level.

Adam has also designed Automated Test Equipment (ATE) systems for verification and validation of safety-critical applications. His design approach utilizes as much off-the-shelf hardware as possible with a common software architecture to minimize costs and development time between projects. His ATE designs have been used in testing high input/output (I/O) products for military, aerospace, and industrial applications.

Adam is a Functional Safety Certified Automotive Engineer (FSCAE) and has spent most of his career working on safety-critical projects. He has developed software for Aerospace DO178 Level A products, and hardware and FPGA designs for safety-critical products in the rail and industrial machine tooling industries. 

Adam attended California Polytechnic University Pomona and has a Bachelor’s of Science in Electrical and Computer Engineering. He also has an Embedded System Engineering Certificate from the University of Irvine.

Interviewee: Nathan Haynes 

Nathan Haynes has served as a senior software engineer and application software technology grouping leader for LHP Engineering Solutions since 2014. He develops enterprise-scale web, mobile, and desktop-based applications for multiple OEMs and tier one organizations. He has worked with customer IT organizations to architect applications within their security and infrastructure requirements. In the past several years, Nathan has moved into the areas of application lifecycle management (ALM) and automated test systems. Using his experience with systems integration and communication protocols, he has developed unique approaches for the integration of these systems to help bridge the gap required for compliance with ISO 26262.

Nathan has experience in security auditing of web applications in regard to cross site scripting, SQL injection, broken authentication and session management. He is a full stack developer and has experience in both software/database development as well as IT and cloud infrastructures.

He began his career as a web and database developer in the healthcare IT industry, focusing on developing software that interfaced with a hospital’s Health Information System. His move to the automotive industry found him connecting factory floor PLCs to database-driven applications. This new technology enabled Nathan to develop business intelligence infrastructures to provide strategic decision-making information used by management.

Nathan holds a Bachelor’s in Computer Science from the University of Southern Indiana and lives in Brownstown, Indiana.