How to Plan for Large Language Model (LLM) Adoption Within Your Engineering Organization
The initial free and unprotected access to ChatGPT (the most well-known Large Language Model) has led some individual engineers to try out the tool by using company owned trade secrets and intellectual property (IP) as prompts. The predictable result has been IP leakage with numerous high-profile examples, including at Samsung. As a result, many companies, including Apple, have banned internal use of the technology outright. Additional risks are just starting to be understood given the lack of consent provided by the actual owners of content that was used to train the LLMs. This leaves the concept of ownership of LLM output, and the ability to protect intellectual property that includes LLM output in question and legal experts are advising caution. Clearly, it will take some time for legal frameworks and precedents to be established for the use of LLMs in product development and for enterprise-class integrations to be developed to LLMs that at properly allow for company level standards and governance of IP. Numerous lawsuits, such as Clarkson v OpenAI, are now underway alleging all of the data to train the LLMs was obtained without consent or renumeration and violates copyright law.
Clearly, it will take some time for legal frameworks and precedents to be established for the use of LLMs in product development and for enterprise-class integrations to be developed to LLMs that properly allow for company level standards and governance of IP. Given the risks and unresolved legal questions LLMs pose for product development, how should an engineering organization plan an adoption path to achieve potential benefits from intelligent assistance for engineering tasks?
The guidance we provide our clients is to focus on the following three areas, ranked in order of greatest benefit from intelligent assistance:
Improve requirements quality – Poorly specified requirements account for up to 64% of defects and are the costliest ones to correct. The International Council on Systems Engineering (INCOSE) and the Easy Approach to Requirements Syntax (EARS) have established best practices for requirements specification and unfortunately, LLMs are trained on publicly available requirements content that is rife with all the most common errors addressed by INCOSE and EARS. The best intelligent assistant to improve requirement quality is a Natural Language Processing (NLP) approach that analyzes requirements against INCOSE and EARS best practices and recommends improvements – which is exactly what Jama Connect Advisor™ does. Jama Connect Advisor protects all IP and engineers learn how to write better requirements through intelligent guidance.
Manage by exception – The engineering function is one of the last in the enterprise to be managed through data. The engineering process is often fragmented across teams and tools which leads to late identification of cross-discipline issues that result in defects, delays, cost overruns, and recalls. Jama Connect® intelligently solves this problem through Live Traceability™ which automatically syncs data across best-of-breed tools and tracks engineering progress against the chosen development model (e.g., V-model) to identify issues as early as possible and thereby reduce the risk of defects, delays, cost overruns, and recalls.
Increase engineer productivity – The biggest drains on engineering productivity are most commonly integration meetings and rework. Jama Connect’s Live Traceability intelligently alerts teams to impactful change from other engineering disciplines. Live Traceability eliminates the need for time-consuming and mind-numbing integration meetings and is proven to reduce rework based on our groundbreaking benchmarking study. Further productivity gains can be achieved by leveraging LLMs for requirement decomposition and we intend to be one of the first to market with an enterprise-class solution that protects IP and enables company standards.
To get started with intelligent assistance, learn how best to improve requirements quality across your engineering organization with the NLP application of EARS and INCOSE best practices.
In this blog, we recap the “An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Diagnostics Regulation (IVDR)” webinar.
Looking to stay ahead of ever-evolving regulations governing medical devices?
In this webinar, we discuss the continual rollout of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR) and the impact they’re having on the medical device industry.
Vincent Balgos, Director of Medical Device Solutions at Jama Software and Saby Agai, Sr. Consultant at Jama Software, provide a high-level overview of the new regulations, along with general industry observations and future considerations for organizations with medical products marketed in the EU market area, including:
New classifications, grandfathering clause, and risk management requirements
The number of notified bodies, backlog, and remediation efforts for placed products
Future considerations regarding the compliance compatibility of IVDR & FDA and traceability
Finally, learn how the Medical Device Framework in Jama Connect® can help streamline your compliance efforts and ensure your products meet all the necessary regulatory requirements.
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Saby Agai: So, in the first part of the webinar we will talk about the EU medical device regulations. There is a small agenda to that. Basically, we would like to show the key changes and challenges that the MDR means compared to the MDD. We would also like to talk a little bit about what we see as the challenges for the process transformation of the medical device developers and also a bit of discussions with the race on the timeline for the MDR. The second section is on the MDR for the MedDev engineering. So basically, how the engineering teams can do anything with the MDR. We’ll talk about harmonized standardization. How does that fit in the concept of the MDR? And some of the medical device best practices that we would recommend. So the medical device regulations now has quite a bit of history because the MDR is valued also for existing [inaudible 00:04:15] devices and also for all the new devices.
The medical device regulations entered into force historically in May 2017, and there was a bit of extension period in 2020 that the certificates issued under the MDD before the MDR remained valid up to four additional years. So it was a bit of a time extension for manufacturers to migrate the legacy devices to the MDR. Recently 2023, the EU commission had the new rule based on 607 was the number of it on the time extension for the medical device regulations. So there are two-time extension now in force for December 2027 and 2028 for all devices. As part of this modification, the commission removed the sale of period from the original context of the Medicaid device regulation.
Three key area that we would mention that we see as key challenges with the MDR is first is the technical documentation. So because of the legacy medical devices has to be reclassified in a context of the new MDR, those manufacturers highly likely will face it extended set of documentation for market clearances in the EU. It’s particularly true for software as a medical device because, basically the class one level has removed by legislation for all software as a medical device. The other thing on the technical documentation is that the MDR is far more prescriptive about the requirement content of the technical documentation, and it’s particularly true and there are more detailed requirements needed for the quality management system. So the manufacturer will have to ensure that they not only have full access and control for the documentation of the device, but also they should keep the eye on the market and the vigilance market, post-market vigilance area, as well as publication or new common specifications.
Agai: So there is a bit of higher focus on the post-market activities in the context of the MDR. And the technical documentation basically has two key parts in Annex II, annex III it’s detailed. Annex II there is a list of requirements for the technical documentation itself for the device design, and also, in Annex III, we see details or requirements for technical documentation post-market surveillance. So nothing particularly new, only an extended set of expectation and requirements for all these contents. Little note something on the technical documentation. So historically, the technical documentation has a tradition to be seen as a burden on the med tech developers and additional administrative work. And quite often, at the end of the development cycle, there is a massive effort made to make what is documentation available for regulators and also for market clearance. It definitely could require very intense administrative work from the engineering sometimes stress involved and also, the content creation has not much help or not much support for the regional engineering activities, which is the development.
So these content created purely to support the market access activities and it should not necessarily should be a case, though. So, for example, we in Jama has a medical solution. It’s a example proven a tool actually can support both med tech developers to enhance the development efficiency as they develop a new device as well as to support these technical documentation needs at the same time. So it’s a opportunity also for organizations to get most out of using a tool when they thinking about to ease the burden of the medical device regulation technical documentation part.
Agai: Thirdly but not lastly, there was a new, particularly in EU requirements for the unique device identifier. So basically, 2021 was a deadline to register an MDR UD MDR devices with the UDI in the [inaudible 00:09:02] framework, and for the IVDR, it’s 2022. Looking into purely on the numbers, we could say that the content of the MDR compared to the MDD is actually four time heavier. So the extent and the legal tax basically is four time more. There are five plus on axis that we can see, and there is a special attention on safety and patient safety particularly because 293 times mentioned the safety word in MDR where in the MDD was the 24. All these numbers also telling that the regulators in EU want to have higher scrutiny compared to the MDD, and they also have more details on that level of expectation that they would like to see from manufacturer. And there is a definite focus on patient safety that we can see.
Two more things to mention is that quite often, in the context of the MDR, the legacy devices should be reclassified into a higher level class. So it means that the quality management process support is more intense, and more support expected. More activities and works are expected from the manufacturer to keep the same device basically on the market. It also could mean that companies should take a step for high-level maturity as an organization and it’s true also for the design and device development activities. So one of the challenge with that is that if we talk about the same device with higher regulatory scrutiny, how do we retain and enhance profitability? Because the administrative burden is definitely something that goes towards the cost part of the profitability. So the design and development goes under higher level of process expectation in that sense, and it goes higher level of design documentation needs as well. So one of the advantages using the tool in general medical device environment that the medical solution can ease actually this work and enable a bit quicker, and the developers can leverage a little bit more help on these challenges.
In this blog, we recap the “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System” webinar.
In this webinar, “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System”, learn about the implementation of the Threat and Risk Analysis (TARA), the centerpiece of the new Automotive Cybersecurity standard ISO 21434.
Many companies currently use spreadsheets to develop TARAs, which can be challenging when managing large sets of requirements across distributed teams and car line variants. In this webinar, we’ll examine why a requirement management system (RMS) is well-suited to manage the TARA work product and can make a significant impact on managing this data across teams, supporting compliance audits, and assessments.
Attendees will gain insights into TARA’s complexities and how the right tooling solution can make a difference in managing this data across teams, supporting compliance audits and assessments.
Key Takeaways:
The Threat and Risk Analysis or TARA is the centerpiece of the ISO 21434 Automotive Cybersecurity standard
Overview of TARA
ISO 21434 compliance requirements when implementing TARAs
Why an RMS is well-suited to manage TARAs
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Kevin Dibble: Thanks, Juliet. Okay. I’m going to just go through the agenda and then get right into 21434. I’ll start with a high-level introduction and then get into the focus of our topic today, which is the threat and risk analysis, which is a centerpiece of 21434, also known as the TARA. And then make an argument for the management of a TARA using an RMS or a requirement management tool. And then Steve will take over and talk about what that would look like in Jama software and summarize with some key points of managing TARAs in Jama versus some traditional methods. And then we’ll have time for some questions.
So with that, again, this is going to be a very high-level overview of 21434. I have a feeling that some of you have worked in cybersecurity for some time, others are just brand new to the term. And so, I want to touch on this as a basis for the rest of the discussion.
And so, first, what is 21434? It is the automotive industry standard for developing cyber secure systems. After several years of review, it was approved in August of 2021 as the method for developing cyber secure systems. In terms of the standard itself, it’s structured and uses a lot of the same terminology as the functional safety standard called ISO 26262. So if you’re familiar with functional safety, then this standard will make a lot of sense the way that it’s organized. Some of the terms such as an item definition, a concept phase, a cybersecurity goal, even TARA parallels functional safety terms like functional safety concept, functional safety goals, or the HARA, Hazard and Risk Analysis. And so, that’s just a reference point as you’re learning about this new standard. Now as far as its scope, it covers or it applies to passenger vehicles and cargo vehicles.
So just a little bit different than ISO 262 there, passengers would include buses, commercial or non-commercial. I think even tripods and some of those other types of motorcycle hybrid type of devices are in or vehicles are in scope as well. It applies to series production and it uses a lifecycle that starts at the request for a quotation for an item. And I’ll define that in a little bit and goes all the way through to the end of cybersecurity support. So like functional safety, we’re not talking about supporting the risks and the hazards associated in this case with threats from attackers leading up to SOP, but it extends far past that. In fact, in 21434, instead of using the term SOP or start of production, which is a critical milestone in any automotive product development program, they call that milestone the release to post-development.
Dibble: And I want to camp on that for just a second because it raises a really important point and it’s very relevant to what we’re going to talk about regarding the TARA. Release to post-development. So the automotive industry is under a lot of change and OEMs want to be or are becoming mobility providers and services will be sold after the car is released. And some of those services weren’t even imagined at the time the car was sold. That’s so different than where the automotive industry was even five years ago. And this standard recognizes that and embraces it along with another important concept, which is that the world of cybersecurity and the landscape for threats and the technologies and the tools that are used to attack vehicles is constantly changing. And so, at the release to production, what is assumed to be protected in terms of say a set of cryptographic keys or a communication bus might be more vulnerable in five years than it was when the car was released because of new techniques, new methods, new tricks, new hacks, and other things that have been discovered.
And so, that’s an important concept because it feeds to our idea that we’re going to get into about the TARA as a living document, as a living asset that begins all the way at the concept phase at the beginning of the high-level architectures of the item or the system in the car. And extends all the way until the end of life for cybersecurity support, which is 10, 15 years down the road. Now, the 21434 has both requirements for developing cyber secure systems, is kind of what I’m showing you on the right, but it also has process requirements. And to that end, there is an audit of the process and an assessment of the results of your project according to 21434. That assessment piece is important for our discussion because when we think about the TARA and the pieces of it or the items of the TARA, then we have to think in terms of what are the evidences we need to leave behind and produce in order to pass an assessment, very important consideration.
Dibble: And so, we have audits for the processes and then assessments for the end result. So that’s very brief overview of 21434. I want to make sure I leave you with the… If you remember anything about 21434 besides the TARA, you’ll hopefully remember this, is to manage unreasonable risk of damage to road users due to a malicious attack to a vehicle or a vehicle data, confidentiality, integrity and availability. Let me unpack that for just a second. Unreasonable risk, this is when you get into a car, when you operate a vehicle, you assume some risk. But that risk doesn’t include driving down the highway at 70 miles an hour, turning right and the car going left or the headlights going off while you’re on the highway at night. It applies to road users. That’s the people that use the road, the driver, the passengers, and the people surrounding it.
All of that is our scope for how we’re going to define threats according to 262 and then mitigate them against malicious attack due to… That’s the cyber aspect of this. And then what’s being attacked and what are we protecting? We’re protecting vehicle systems, functions, data, et cetera. We call them assets according to their properties, confidentiality, integrity and availability. There could be more properties, that’s the CIA that we’re protecting. Why is cyber such a hot topic? Well, I would say there’s several reasons, but here’s two of the big ones. On the left of my slide, the advent of the connected car coupled with the automated driving functions. I’m not going to read through all the stats here, but the connected car is here. It’s 2 billion in terms of the market in 2021 to grow to $5.3 billion in 2026. And the connected car is accessible via the internet, accessible via Bluetooth and other network interfaces, which all result in attack services. It also has a lot more software.
In this blog, we recap our press release, “Jama Software® Delivers Major Enhancements to the Jama Connect® for Airborne Systems Solution” – To read the entire thing, click HERE
Jama Software® Delivers Major Enhancements to the Jama Connect® for Airborne Systems Solution
Accelerate and optimize airborne systems development with a new set of supported frameworks, projects, and standards
Jama Software®, the industry-leading requirements management and traceability solution provider, has announced enhancements to its Jama Connect® for Airborne Systems solution. Jama Software is committed to continuously enhancing its industry solutions, enabling customers to easily manage requirements, achieve Live Traceability™ and accelerate systems development.
The Jama Connect for Airborne Systems Solution is a complete set of frameworks, example projects, and procedural documentation used to accelerate the implementation of Jama Connect for organizations developing airborne systems and components. This is the third major upgrade to the solution since 2019 and these new capabilities are available to existing and new customers alike. The update both refines the existing solution elements and expands the scope of the solution to meet airborne safety and cybersecurity standards ARP4761A and DO-326A respectively.
“Having all of the applicable 14 CFR regulations preloaded at the beginning of a new project greatly accelerates assigning the driving requirements without extensive data entry.”
Jeffrey Spitzer, Chief Engineer at Transcend Air
The newly upgraded Jama Connect for Airborne Systems provides the following benefits:
Reduced adoption time of new standards such as ARP4754A/DO-178C/DO-254/ARP4761A when developing complex airborne systems
Reduced deployment time and risk of negative outcomes with defined and justified configuration, export templates, and reports
Increased confidence and decrease time-to-value with an established scope and direct alignment of requirements for Airborne Systems
“Jama Software continues to lead with innovation and work alongside our customers to invest deeply and cater to the needs of the Aerospace and Defense (A&D) industry. The Jama Connect for Airborne Systems solution has enhanced support and provides a standards-compliant framework that can streamline compliance demonstration for aviation system development. This is a major milestone for us! And we are here to help our customers stay ahead of the rapidly changing Aviation industry.”
Cary Bryczek, Director of Aerospace and Defense Solutions at Jama Software
The Jama Connect for Airborne Systems Solution consists of multiple components that make up a ready- to-use configuration including:
Airborne Systems Dataset: Includes frameworks and sample sets aligned to ARP4754A, ARP4761A, DO-178C, DO-254, DO-326A along with US Code of Federal Regulations Airborne Systems Library (eCFR) – pre-imported Title 14, Subchapter C, Parts 21-59.
Procedure Documentation and Reports: The procedure documentation provides teams with straightforward processes that they can follow to make the best use of Jama Connect in compliance with the standards included in the dataset.
Data Exchange (Add-On): This utility allows the exchange of requirements, architecture, and tests across the supply change and between tools using the industry standard ReqIF format.
Success Program (Add-on): Includes an Aerospace and Defense Jama Consultant to optimize your Jama Connect configuration, teach best practices, and train your team.
“Jama Connect has enabled Ursa Major to document airborne systems requirements and track verification closure in a streamlined and organized way which has enhanced communication and success between our teams.”
Maggie Mueller, Systems Engineer at Ursa Major Technologies, Inc.
To learn more about Jama Connect for Airborne Systems Solution, please visit our Aerospace and Defense page.If you would like to speak with one of our industry experts and book a free Jama Connect trialclick here.
As we enter 2023, Jama Software asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the final blog of this five-part series, we asked Steve Neemeh, CEO / CTO of LHP Engineering Solutions – Danny Beerens, Senior Consultant at Jama Software – and Richard Watson, Practice Director at Jama Software – to weigh in on automotive product and systems development trends they’re anticipating in 2023.
Read more about the authors at the end of this blog.
2023 Predictions for Automotive Product Development
Design Trends – What are the biggest trends you’re seeing in your industry right now? How will they impact automotive product, systems, and software development?
Steve Neemeh: A generation ago software was introduced in engine controls that changed the automotive industry and allowed for efficiency and emissions improvement that mechanical systems could not provide. In today’s world, software is entering a new stratosphere of complexity. Rather than focusing on emissions, the goal is the user experience. High-tech meeting transportation changes the paradigm for automotive companies.
Danny Beerens: I don’t see a lot has changed in this regard. What is changing is what’s being built, not how it is being built.
Richard Watson: Taking advantage of Live Traceability™ will become increasingly important.
Definition of Live Traceability: The ability for any engineer at any time to see the most up-to-date and complete up and downstream information for any requirement, no matter what stage of development it is in or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real-time.
Biggest Challenges – What are some of the biggest challenges you think automotive companies will be working to overcome in 2023?
Neemeh: The commercialization of the zero-emissions vehicle is the biggest challenge for 2023. The price points are a challenge. The supply chains are limited and not optimized for worldwide expansion. And, the energy grids are outdated in many places, such as California.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Beerens: More and more brands will move to electric vehicles, making those vehicles and specifically their motor management components more software driven. The various other components (primary functions, driver assistance/automation, as well as onboard entertainment) will also become more electronically controlled and thus software driven.
[Side note] Autonomous driving vehicles even sparked new fields in Software Engineering, like Ethical Software Engineering (studies the interactions of human values and technical decisions involving computing).
Clearly the Automotive Industry is shifting from Hardware/Mechanical Engineering and Electo-Mechanical to Software Engineering, forcing Product Data Management, or Product Lifecycle Management, vendors to start including Application Lifecycle Management into their environments. Hence you see Siemens Teamcenter has acquired Polarion and PTC Windchill acquired Codebeamer recently.
The Holy Grail will be an ALM/PLM environment that truly embraces Configuration Management for all engineering disciplines involved, combined.
Anticipating a new player not hindered by their already existing PLM or ALM application, neither their customer base, to develop a truly all incorporating ‘Engineering Assets Configuration Management’ environment, platform or application.
For the next decade, next to fully autonomous driving vehicles, flying cars might be the new way to fight congestion and a more personalized way to get around.
Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2023?
Neemeh: With any new products in automotive, recalls will drive governments to regulate safety more closely. Functional safety is now a common term in automotive and most large OEMs are trying to find a way to comply and keep themselves from facing potential liability. The implementation of functional safety in the software development process will keep inching forward until a trigger makes it mandatory.
How do you foresee regulations shifting in Automotive Product and Systems Development over the next decade?
Beerens: Certainly, autonomous driving will introduce regulations to control not only functional safety and cybersecurity, but also for road safety (and legal responsibility) to interact with non-autonomous driven cars, until we’ve reached an era where none of us drive ourselves and all cars are controlled centrally to manage traffic flows.
Demands on alternative powertrains (e.g., hydrogen, or fuel cells) and existing electric driven cars’ necessity for fast charging and/or quick exchange of batteries, will spark off new technologies.
Apart from the obvious increase in data points and data exchange of the vehicle itself (sharing information for predictive maintenance, or usage of the car; tachograph in trucks) and its manufacturer and/or service station, G5 Connectivity of (autonomous driving) vehicles interacting with new traffic control instruments in, next to or on the road that assist with difficult traffic situations (automatically move to the side to allow emergency vehicles to pass), or location (purposely slow down at intersections that don’t have clear visibility of oncoming traffic) and react to traffic lights.
As a reaction to reduce CO2 emissions (cars sales are in a slow decline for a few years now already) new forms of mobility will arise where MaaS (Mobility as a Service) are being offered, sparking off disruptive newcomers to the traditional car sharing companies (renting: Hertz, and even taxi: Uber), like for example Lynk&Co, offering “memberships” for more flexible car usage and for car sharing with family and friends.
Tool Innovation – From an automotive engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process and why?
Neemeh: Functional safety requires a strict development process and tools that support that process. Traditional tools only meet a small piece of that. They need to be integrated into an overall workflow and safety culture.
Any major disruptions to the Automotive Product and Systems Development industry you’re anticipating in 2023?
Watson: Political environment, supply chain issues, increased cost of specific items (such as chips). This increased cost is pushing the buyers into higher income areas, changing what kinds of cars will be successfully built.
Because of cost issues, refurbishing and retrofitting existing cars will become increasingly important. Similarly, car sharing will be increasingly wanted to control costs.
What role will cybersecurity play in automotive development in the coming year and beyond?
Neemeh: Safety can’t be achieved without cybersecurity. Assessment of your system’s vulnerability and its inclusion in your safety case is key to overall product acceptance. The more that cars become connected, the more this becomes important. Autonomous driving will be the pinnacle of connected cars. The more we move in that direction the more cybersecurity becomes a concern.
What sorts of process adjustments do you think development teams will need to make to be successful in 2023?
Watson: Automotive systems continue to have a stronger focus on software and this shift will continue. Different categories of software are provided in a vehicle from safety-critical to entertainment and this drives complexity sky-high.
With regulations continuing to get more stringent, development practices for non-safety-critical software systems must be tightened and this drives a focus to improve Agile practices. “Agile” is not an excuse to “throw something together” and must be supported by improved specification and verification techniques.
In your opinion, what are the biggest differences between an automotive company that survives to see 2030, and one that doesn’t?
Neemeh: Getting prototypes on the road and small-scale production with new technology (EV/Autonomous) is a monumental feat. The next step, however, is the commercialization of that technology into a transportation industry that is concerned about public safety. Those that consider that in the rollout and enable the scaling of safety-critical infrastructure will win, while the others will hit a brick wall of regulation.
Watson: A combination of sustainability with control of spiraling costs. There is a world shift in planetary awareness and the automotive market is at the forefront of reducing our consumption of fossil fuels. Car prices are increasing beyond inflationary rates and this increase will price out much of the lower market. Only organizations that can shuffle sustainability, quality and costs will survive this decade.
What role will cybersecurity play in automotive development in the coming year and beyond?
Watson: A shift towards Internet of Things (Iot) has exposed almost all aspects of automotive systems to the internet and social media. Cybersecurity will take a stronger focus, especially for those software systems that already interact with our social networking applications.
Beerens: Not only for our social networking applications; for long all systems utilizing the various onboard connections simply accepted instructions, without checking if that instruction was from a valid source. The infamous hack of a Landrover during Black Hack 2014 proved that. Encryption and intrusion detection are a good line of defense, but Zero-trust (or validating the source of the commands) Cybersecurity will be increasingly important for onboard systems from entertainment systems, connections like CAN, wifi, bluetooth or NFC, to motor management.
What advice would you give to new companies entering the automotive industry?
Neemeh: Get your workflows set up and your tools ready and optimized before you start throwing bodies at problems. Engineers are expensive. When they are set up properly, they can create miracles. But if they are burdened with administrative problems, they will get frustrated and leave.
Beerens: Look at established tool chains and industry templates to have a running start at the get-go. The European Union has an advisory board with such tool chains and templates. Concern yourself with compliancy from the beginning. Which compliancy standards you concern yourself with will depend on what parts of the auto you are working on.
Watson: Don’t try and define and invent the wheel and get help. There are many development tools available, find which tools work best based on tool reviews. Once selected, ask the vendor for the best way of working and don’t force the tool to do inefficient practices.
What topic(s) do you wish companies were paying more attention to?
Watson: Understanding how to address complex problems without the systematic nature we have relied upon. This is the only way to keep control of costs.
Predictions – What do you think will remain the same in your industry throughout 2023?
Neemeh: The adoption of electric vehicles will continue. Governments are behind it and the adoption rate is increasing.
What do you predict for regulation in the Automotive industry in 2023?
Neemeh: Involvement in the design process and review of ADAS features will become more important. The NHTSA has already started putting frameworks in place for that in the USA. In Europe, functional safety is commonplace and regulated already.
Will those trends still be prevalent 5 years from now? 10 years?
Neemeh: Yes, and it will move as fast as ADAS features move forward. Any autonomous Level 5 applications will jump-start this trend.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?
Watson: Jama Software® is perfectly positioned to help the automotive industry allowing extended stakeholders to be directly involved with authoring and reviewing specification and verification activities rather than relying on tool super-users and PDF reports.
Beerens: Jama Connect® is a perfect fit for Product Design and collaboration with all its Stakeholders to refine, expand and improve Product Design, before any of these (proposed) changes are even visible in a PLM environment thereby preventing disruptions in Production before consensus has been reached.
——————————–
About the Authors:
Steve Neemeh joined LHP in 2015 to lead the expansion of the west coast operations. He is the leader of the strategy and solutions architects as well as president of the delivery consulting organization. Steve has over 25 years of Functional Safety experience prior to joining LHP. Steve has launched multiple start-up operations and has taken them to full production. Notably, a complete ground up electronics and software development group to service commercial aerospace electronics and military vehicle power electronics. For LHP, Steve pioneered the implementation of safety critical applications in California, launching functional safety for autonomous driving applications as well as air mobility.
Danny Beerens has 15 years of experience implementing, training, maintaining and supporting Application Lifecyle Management processes and their environments. Danny started in Software Configuration and Change & Defect Management (i.e., Workflows.) After joining Telelogic, he moved into Requirements and Test Management over the last decade, in roles as Support Engineer, Process Engineer, Consultant, and System Architect. Throughout his career Danny’s worked on projects and collaborated with customers in the Medical Devices, Aerospace & Defense, Automotive, and Semi-conductor industries. “The need to integrate ALM and PLM (and even beyond!) is apparent across all industries.”
Richard Watson is the Practice Director for horizontal solutions, engaged in identifying and creating services and assets spanning the Jama Software vertical solutions. Richard has a client first attitude and is passionate about Requirements and Systems Engineering. Based in the UK, Richard has been working in the systems and software industry for nearly 35 years and has been directly involved in most aspects of Systems Engineering from testing flight systems, through to software development of modeling tools, and Product management of IBM DOORS. Richard joined Jama Software as Practice Director in 2021.
As we enter 2023, Jama Software asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the fourth part of our five-part series, we asked Shawnnah Monterrey, CEO at BeanStock Ventures – Romer De Los Santos, Senior Consultant at Jama Software – Vincent Balgos, Director of Medical Device Solutions at Jama Software – Michelle Wu, Medical Device Consultant at Wu Consulting – and Ivan Ma, Medical Device Program Leadership – to weigh in on medical device product development trends they’re anticipating in 2023.
Read more about the authors and their organizations at the end of this blog.
2023 Predictions for Medical Device Product Development
What are the biggest trends you’re seeing in the medical device and life sciences industry?
Shawnnah Monterrey: Biggest trends we are seeing include a rapid migration to the cloud this includes: IoMT, Digital Health, Digital Therapeutics and Big Data such as Genomics, Biotech, and Pharma.
We are seeing a rapid shift towards newly derived clinical insights using pre-existing data from existing medical devices, such as:
Companion diagnostics which combine a diagnosis outcome with a therapeutic and monitoring of that treatment
Digital therapeutics which use software ONLY to treat patients as opposed to a drug or instrument
Novel clinical insights where two or more measurements are combined to produce a clinical determination
AI based diagnostics which often consume numerous inputs that could be measured, demographical or even genetic to derive new clinical insights
Romer De Los Santos: Digital health continues to be a major source of growth as personalized medicine, wearable devices, and mobile health gain wider acceptance. Cloud computing, AI, and machine learning are improving patient outcomes by encouraging innovation and making personalized medicine possible. As these constantly evolving technologies continue to grow in complexity the regulatory framework around medical devices that incorporate them are also evolving to keep up.
For many years, medical device manufacturers secured their devices by disabling or designing out interconnectivity. The rise of electronic medical record keeping has forced manufacturers to support limited interconnectivity. They usually depended on security measures taken by their customer’s IT department as the primary risk control measure. That’s no longer acceptable in our interconnected world. The FDA requires manufacturers to consider cyber security threats and to design controls to reduce these risks as much as possible. This has led to developers having to learn more about threat modeling to limit touch points into their software and to creating plans on how to handle data breaches.
The 21st Century Cures Act amended the definition of a medical device to exclude certain software functions. The FDA intends to focus oversight on software functions that affect patient data and therefore pose the greatest threat to patient outcomes. Wise developers architect their software systems based on clearly defined software functions that can be individually evaluated for risk, leading to a reduction in the regulatory burden. Designing and documenting modular software facilitates re-use and therefore faster time to market for novel medical devices.
Michelle Wu: AI and Machine Learning: I continue to see AI and Machine Learning as a trend for 2023. Any pitch competition I attend includes multiple products that are incorporating AI or machine learning. There’s attention now on companies to look for and counteract bias in the data sets and algorithms.
Health equity: A spotlight on health inequities shines brighter since the pandemic and fortunately many companies are looking to do good and do well. Telehealth, remote patient monitoring, digital health apps, are the top areas of innovations that I see to address these disparities.
Vincent Balgos: The pandemic continues to drive the industry, regulators, and the market for COVID-19 related products and services, so I would expect continual development in these areas as new SARS-CoV-2 variants emerge, or other as other diseases arise.
Continual integration of medical life products, and interoperability amongst devices. As software to grows as a critical part of medical device industry, whether standalone SW or integrated with other components, there are many areas for 2023 innovation such as:
Software as a Medical Device (SaMD), Software in a Medical Device (SiMD)
Cybersecurity
Complex data analysis such as bioinformatics, genomic sequencing, imaging processing
Artificial Intelligence (AI) and Machine Learning (ML)
New or modified regulations (EU IVDR, EU MDR, and potential US VALID Act) continue to change the landscape in how medical device and life science organizations develop, manufacture, and maintain products.
The new FDA Computer Software Assurance (CSA) guidance that revisits validation in context of the current Computer System Validation (CSV) approach. Many medical companies are looking at this new risk-based approach to streamline their activities, documentation and outputs as the current standard practice can be complex and cumbersome.
Biggest Challenges – What are some of the biggest challenges you think medical device and life sciences companies will be working to overcome in 2023?
Monterrey: Two of the biggest challenges I see are: monetization and regulatory clearance.
Medical devices revenue models rely heavily on reimbursement from CMS which require a CPT code. Obtaining a new CPT code requires a significant investment and burden on the medical device manufacturer to provide clinical evidence which not only shows efficacy but also provides A reduced cost of care when compared to existing methods and treatments. We are seeing that digital therapeutics are struggling in this area. One strategy has been for digital therapeutics to partner with an existing reimbursed pharmaceutical via revenue sharing. But on the upside CMS has recently provided a new code which allows prescription digital behavioral therapy to be reimbursed as a medical benefit which is trailblazing the path for other digital therapeutics to follow.
While digital health applications that are intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease are medical devices and have been regulated by the FDA for many years, there has been new entrants in the recent years that have gone under the radar. With the recently issued guidance from the FDA on Clinical Decision Support Software, FDA attempts to make it clear which products are regulated medical devices, and which are not. This will slow the reduction in the barrier to entry as many digital health applications begin to play catchup.
Ivan Ma: The supply chain for components and materials continues to remain constrained. With lead times stretching well past 6 months, and sometimes getting close to 12 months. Programs should plan for contingencies and with expectations that milestones that require physical materials will be impacted by the last part in. Be wary of strategies that start early but require more total effort to execute.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
De Los Santos: The need to ensure traceability between requirements, testing, risk, and design will continue to be important in the next decade. Changes in what is considered medical device software will lead to revised regulatory strategies by companies agile enough to take advantage of these changes. Documentation must become more modular to match the software they describe.
Balgos: Based on my past 17 years in medical product development, the time pressures to launch safe and effective products quickly to the market has always been a constant theme.
Many attempt the “faster, better, cheaper” approach, but schedule has always been the driver when comes to the project’s managements iron triangle (scope, budget, schedule). While this “faster, better, cheaper” approach may work for other industries, the medical field is especially constrained in that a patient’s safety is non-negotiable.
What will change is how companies adapt to the complexities of the regulation landscape, innovative technologies, and ever growing knowledge of diseases, illnesses, etc. The adaption for advanced tools, processes, and digitization of information will continue to grow industry as scientists/engineers evolve their practices.
What changing regulatory guidelines do you anticipate having an impact on companies in 2023?
Monterrey: In addition to FDA’s guidance on Clinical Decision Support Software there are a few other draft guidance in the works such as Computer System Validation (CSA), Cybersecurity, and AI.
Tools that are used to implement part of all the quality system require validation to ensure that the tool is fit for purpose and mitigates the risk of failures that could pose undetected harm in the medical product. We have seen many of our clients spend significantly more effort on validating tools that do not pose significant risk to their medical device than the medical device itself. FDA’s Computer Software Assurance for Production and Quality System Software draft (CSA) guidance provides great insight on how to take a risk-based approach when validating your tools.
Cybersecurity affects all products in development and on-market, regardless of if they are fully embedded or even connected. For medical devices manufactures that have many legacy devices on-market, this new guidance can pose a significant risk and cost.
Artificial Intelligence and Machine Learning (AI/ML) Software as a Medical Device Action Plan provides some additional insights into FDA’s current thinking behind AI. Although there is no current guidance from the FDA, AI devices continue to be cleared under existing guidance increasingly year or over.
Balgos: The US VALID ACT could have major disruption to lab developed tests (LDT’s) and how they are regulated in the US market. The additional restrictions may impact the growth of new tests, but provide additional oversight to help improve safety. This controversial topic has been a continual discussion point in industry, and that the new VALID ACT provides some additional clarification and guidance.
How do you foresee regulations shifting in medical device and life sciences over the next decade?
De Los Santos: There is a growing understanding among regulatory bodies that cloud computing companies are developing technology that will significantly improve patient outcomes.
Tool Innovation – From a medical device and life sciences engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process and why?
Monterrey: From an engineering toolset perspective – finding automated tools that support the regulation and the team’s ability to be agile for the full development cycle will have a significant impact. Typically, we see our clients taking 6 to 18 months back tracking design activities in order to satisfy the FDA when the product is almost completed. If development is done in a more automated and iterative way – time to market can be significantly reduced, more predictable and lead to higher quality products.
Wu: Tools that make regulatory compliance more efficient. The best tools make it easy for companies to enhance, instead of hampering, their product development and business strategy.
Human centered design. While not a new concept, it is not universally practiced and incorporated. Those that do this well have medical devices that resonate with users and have better product adoption.
Ma: Requirements matter more than ever. Avoid building the wrong thing by keeping track of requirements and risks management using a tool like Jama Connect. If you are paper tracing, you’re operating in the 20th century.
Any major disruptions to the medical device and life sciences industry you’re anticipating in 2023?
De Los Santos: AI, machine learning, and cloud computing were instrumental in the response to the pandemic but have far bigger implications for improving patient health. As companies shift focus away from the pandemic, I expect more innovation around personalized medicine and clinical decision support software, both of which take advantage of these emerging technologies.
Balgos: The US VALID ACT could have major disruption to lab developed tests (LDT’s) and how they are regulated in the US market and industry.
What sorts of process adjustments do you think development teams will need to make to be successful in 2023?
De Los Santos: Development teams should take advantage of the guidance on software functions to improve the architecture of their code and their documentation. The sooner development teams create re-useable code and documentation building blocks, the better.
Balgos: Aligning with new regulations, such as the potential VALID ACT, and new FDA draft guidances such as CSA, Human Factors, and others
For the EU market, organizations need to start early. Notified Bodies engagement as the backlog continues to be longer than expected for re-certification for Medical Devices and IVD’s to the new regulations.
In your opinion, what are the biggest differences between a medical device or life sciences company that survives to see 2030, and one that doesn’t?
Monterrey: Companies that strive to maintain agility while being regulated leveraging tool automation as opposed to paper-based and stage gate processes will have a competitive advantage and higher chance of survival by having the ability to:
Address cybersecurity demands in an ever-changing eco-system
Derive new clinical insights using real-world data
Innovate by releasing product and features in more frequent cadences
Stay ahead of obsolesce issues
De Los Santos: The ability to organize software, hardware, and documentation into re-useable building blocks are key to winning in this kind of environment. You must be fast while maintaining a level of quality that ensures patient safety.
Ma: Products that bring true clinical value will win in the long run. The challenge is finding organizations and sources of capital that are methodical enough to identify true clinical value and have the grit and determination to stick with programs that take more than 5 years to reach human use.
Balgos: Adapting to the environment will be key for a company’s survival. Whether new regulations, innovative technologies, or another global event changes in how industry operates, companies that has the ability, resources, and willingness to pivot will likely survive.
What role will cybersecurity play in medical device development in the coming year and beyond?
De Los Santos: Cybersecurity is here to stay! The FDA requires device manufacturers to document how they handle cyber security threats and breaches. Companies can’t depend solely on risk control measures made by the customer’s IT department.
What advice would you give to new companies entering the medical device and life sciences industry?
Monterrey: Invest in tools, training, and infrastructure upfront and hire industry and technological experts to help you navigate the complexity of the cloud environment and regulated space.
De Los Santos: Take some time to define a simple design and development process. Don’t overdo it! You don’t get extra credit for adding extra process work. Use a risk-based approach to determine how much is too much.
Wu: Understand that the path to commercialization is much longer for a regulated medical device or therapeutic as compared to a consumer good.
Gain an appreciation for the regulations, what claims you want to make for your product, and how those two impact your timeline.
Human-centered design, including addressing diversity and inclusion, will differentiate your product from others.
Ma: A mentor told me that medical devices are a hard but worthwhile sport. Play the sport with the intent to bring positive clinical value to people everywhere. The rest, as they say, will take care of itself.
Balgos: Understand the market, regulations, and intended use of products/services and the associated risks.
Encourage good documentation practices early and consistently, as documentation is the lifeblood of the industry. Because if it wasn’t documented, it never happened.
What topic(s) do you wish companies were paying more attention to?
Monterrey:
FDA requirements pre-development – implementing a QMS and following a design process.
Customer needs – developing with the end user in mind.
Software as a profit center – focused on the revenue opportunity software can bring.
Tool validation – focus on value-add activities, if you’re spending more time and money validating tools that verifying your medical device you should revisit your QMS for inefficiencies.
De Los Santos: I wish companies would take a little more time cleaning up their processes. Where are you wasting effort? Putting band-aids on your development process costs you more in the long run. What is a working medical product with a poor or non-existent design history file? It’s a brick. It’s a very expensive brick that will require months of remediation work. Design documentation created after the fact is always poor and you’ll also have trouble retaining great engineers if they must spend months remediating documents.
Wu: Women’s Health: While women make up 51% of the population, less than 1% of VC funding is going to FemTech. With an estimated market size of $1.186 Trillion by 2027, the medical device industry is slowly taking notice of the unmet need and market potential of innovation focused on women. Consumer product goods, digital health, and diagnostics are top three product addressing issues unique to women, including menstruation, maternal health, and menopause1. It’s an under tapped area that continues to be prime for disruption.
What do you think will remain the same in this industry throughout 2023?
Monterrey: I think we will continue to see slow economic recovery as a result of the side-effects of COVID as it relates to supply chain, pivots, and lower year end earnings. The businesses that end up striving will be those who are focused on long term strategy as opposed to short term reactions to the economy. Reinvestment and patience will be essential to staying ahead competitively.
What do you predict for regulation in the medical device and life sciences industry in 2023?
Monterrey: There will be a watchful eye on cybersecurity, additional thinking around AI and significantly longer wait times for approval.
Wu: While not significant changes in regulation, the change to MDR and IVDR in the EU continues its impact to the industry, especially as companies’ previous MDD certifications lapse, but have yet to obtain their MDR certifications. As of a July 2022 MedTech Europe Survey Report, >85% of existing medical devices that had MDD certification have received MDR. And unfortunately, it is the patients and public that live in the EU that will be affected when they no longer have access to the same medical devices and diagnostics that they had previously. With the 13–18-month time-to-certification with MDR-designated Notified Bodies, nearly double the time historically needed, this influences the worldwide go-to-market strategy of companies.
Will those trends still be prevalent 5 years from now? 10 years?
Monterrey: Digital health applications will begin to dominate the market over traditional hardware devices with new and innovative, diagnostics treatments and therapies leveraging cloud, AI and real-world data. FDA trends over the next 5 to 10 years will move towards harmonization to reduce complexity and improve ease of use. The reduce wait times the FDA will continue to extend devices in the break-through designation and rely on the use certification bodies or 3rd party FDA reviewers like BeanStock Ventures.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?
De Los Santos: When properly configured and coupled with a simple design control process, Jama Connect significantly reduces the documentation burden for our customers. In the same way that a good source code management system facilitates code reuse, Jama Connect facilitates re-use of requirements, test cases, and risk documentation. There have been some recent improvements to the Jama Connect that I’ve been requesting since I was a Jama Software customer. I hope people take time to take advantage of them.
Shawnnah Monterrey – CEO, Beanstock Ventures
20+ years’ experience in the medical industry, Shawnnah Monterrey knows a thing or two about guiding innovative products to market.
Prior to founding BeanStock Ventures, she obtained a bachelor’s degree in computer science from the University of California, San Diego and an executive MBA from San Diego State University, then went on to hold product development management positions across numerous global firms, including Illumina, Invetech, Medtronic and Carl Zeiss Meditec. Through this work, she continued to develop a passion for innovation in medical devices, life sciences, and biotechnology.
BeanStock Ventures
BeanStock Ventures is 1 of 9 FDA-accredited Third Party Review Organizations globally which provides software development and regulatory compliance products and services to minimize complexity, and reduce cost and time to market of innovative medical devices.
BeanStock Ventures has over 140 years of combined experience in software development for the healthcare and life science space.
833.688.BEAN (2326)
marketing@beanstockventures.com
Michelle Wu – Principal Consultant at Michelle Wu Consulting
Michelle Wu is a senior leader with 20 years of experience in the medical device and life sciences industries with roles in executive leadership, product and process development, manufacturing, and quality. Michelle has a history of successful medical device product development, strategic planning and execution, building teams, process evolution, and managing organizational change. She values a collaborative and diverse, equitable, and inclusive environment, believing that diverse perspectives lead to the best ideas, more cohesive teams, and better results.
Ivan Ma
Ivan Ma has nearly two decades of experience in the medical device industry holding leadership and design positions spanning a wide range of medical devices; from single use devices and active implantables to complex surgical robotic systems. Ivan specializes in bringing early phase projects through development in preparation for FDA submission and human use by introducing balanced discipline to an inherently chaotic process.
Vincent Balgos
Vincent Balgos currently leads the Medical Solution at Jama Software. Prior to joining Jama Software, he worked in the medical device / IVD industry for over 17 years with roles in systems engineering, product development and project management. Vincent has successful history in launching new products to the global regulated market, and is experienced in product development, risk management, quality systems, and medical device regulations.
Romer De Los Santos
Romer De Los Santos has been developing software and firmware in the medical device industry since 1999. He is proud to have been involved in the development of a wide variety of medical devices including insulin infusion pumps, continuous glucose sensors, solid state mobile SPECT cameras, sequencers, liquid handling robots, and various IVD assays. He’s served in the roles of software developer, product owner, scrum master, internal auditor, systems engineer, software project lead, core team leader, and technical product manager before joining Jama Software as a senior consultant this past February.
In part 2 of our blog series, we cover the second half of our eBook, “A Guide to Road Vehicle Cybersecurity According to ISO 21434” – Click HERE for part 1.
Much like other automotive standards, ISO 21434 defines a system engineering V-model to be followed for the development of cybersecurity features.
Concept Development
The cybersecurity V-model starts with the definition of the exact “item” that will be developed. The item is a component or set of components that implement functionality at the vehicle level and is defined in an item definition. In many cases, the same item definition may be used for both functional safety analysis and cybersecurity analysis.
Once the item has been clearly defined, a Threat Analysis and Risk Assessment (TARA) is performed to identify what cybersecurity threats exist for the item and what the risk of those threats are. For threats where the risk must be reduced, concept level requirements are developed, known as cybersecurity goals. Cybersecurity goals form the highest-level requirements for the system being developed from a cybersecurity perspective. For risks that will remain after cybersecurity goals are achieved, cybersecurity claims are documented to explain what, if any, risks still exist and why they can be accepted.
After defining cybersecurity goals, a cybersecurity concept is created. This documents the high-level concept that will be used to achieve the cybersecurity goals. The concept takes the form of cybersecurity requirements as well as requirements on the operating environment.
Product Development
Once a cybersecurity concept has been developed, the system must be designed in a way that will satisfy the cybersecurity requirements. Any existing architecture must be updated to consider the cybersecurity requirements. Each component of the system should be designed to support the cybersecurity requirements.
Although ISO 21434 provides an example of developing a system in two layers of abstraction, no specific number of layers is required. Instead, the standard leaves it to the product development organization to define a process appropriate for the complexity of their system. This ensures that organizations can adapt the standard to a wide range of systems and, for many, means that their existing system engineering process will satisfy ISO 21434.
Once the components of the system have been designed and integrated, the system must be verified to ensure that it meets the cybersecurity requirements.
The methods for verifying the system can include:
Requirements-based testing
Interface testing
Resource usage evaluation
Verification of the control flow and data flow
Dynamic analysis
Static analysis
The integration and verification activities should be documented in a verification specification and the results of verification documented in a verification report.
Validation of Automotive Cybersecurity Goals
While the focus of verification is ensuring that the item meets the cybersecurity requirements, validation ensures that the item achieves the cybersecurity goals. This is done by first validating that the cybersecurity goals are adequate and then validating that the item achieves the cybersecurity goals. Validation may involve reviewing work products, performing penetration testing and reviewing all the managed risks previously identified. A rationale for the validation activities is required. The completed validation is documented in a validation report.
Even after product development is complete, the cybersecurity lifecycle continues.
Production
During the production phase, the item that has been developed is manufactured and assembled. A production control plan is required to ensure that cybersecurity requirements for post-development that were identified earlier in the lifecycle are applied to ensure that no vulnerabilities are introduced during production.
Operations and maintenance
Once an item has been integrated into a vehicle and the vehicle is on the road, new cybersecurity threats can still be identified. ISO 21434 requires organizations to have a plan for how to respond to this scenario.
Organizations must create a cybersecurity incident response plan each time a new cybersecurity incident occurs. This plan includes what remedial actions are required and how they will be performed. The response may range from providing new information to vehicle owners, to over-the-air updates, to recalls where the owner must bring the vehicle in for service.
End of cybersecurity support and decommissioning
Given that the cybersecurity lifecycle continues after vehicles have been sold to consumers, a method for ending cybersecurity support for those vehicles is needed. ISO 21434 focuses on developing a plan for communicating with customers when cybersecurity support ends. Since decommissioning can occur without the organization’s knowledge and in such a way that decommissioning procedures cannot be enforced, ISO 21434 only requires making documentation available to explain how to decommission the item with regards to cybersecurity, if this is even required.
Integrating the Automotive Cybersecurity with Overall System Engineering
ISO 21434 defines many cybersecurity-specific requirements and requires personnel with specific cybersecurity knowledge and skills. Because of this, it may be tempting for organizations to silo cybersecurity engineering activities from other engineering activities, but this would be a mistake. While risk analysis required by ISO 21434 can be considered as a separate activity from other system engineering activities, a single product still must be developed that meets a wide range of requirements, including cybersecurity requirements. For this reason, it is best to manage a unified database for requirements, architecture, and design, rather than tracking cybersecurity artifacts separate from others.
To support this, think of cybersecurity analysis as another input to product development, just like functional safety analysis and market analysis.
By taking a unified approach, a single system engineering V-model can be implemented that describes an overall product development process that incorporates cybersecurity without creating silos. While specialists will be focused on performing cybersecurity analysis, implementing known best practices and validating the final system achieves cybersecurity, this must be done in cooperation and coordination with the rest of product development.
How Jama Connect® Supports Cybersecurity Engineering
One way to implement a unified requirements, architecture, and design database is by using Jama Connect®. Jama Connect for Automotive provides a framework that incorporates the key requirements of ISO 21434 into a single project structure along with overall system engineering.
Specifically, Jama Connect for Automotive provides guidance on supporting the following activities:
TARA Cybersecurity goals
Cybersecurity concept
Design Integration and verification
Validation
An example of the framework is shown below:
Conclusion
ISO 21434 introduces a robust framework for organizations to apply the state-of-the-art in automotive cybersecurity to their product development. This framework is necessary from both a market and regulatory perspective. The high-level of connectivity available in vehicles today means that there many ways for someone to maliciously change a vehicle’s operation. While many consumers may be unaware of the risks today, if there are ever accidents that result from cyber-attacks, that will change quickly. A vehicle OEM’s brand will surely be impacted by such as incident. In addition, regulators have already imposed strong cybersecurity requirements in many regions. ISO 21434 is quickly becoming an essential regulation for companies developing products at all levels of the automotive supply chain.
Whether your team is young or seasoned, small, or large, all together or scattered across boundaries, Jama Connect for Automotive can help improve processes, reduce costs, improve time to market, and help achieve ASPICE compliance. To learn more about Jama Connect for Automotive, download our datasheet.
Interested in learning more about how Jama Connect for Automotive can help provide your team meet market demands more quickly and efficiently?
As the automotive industry becomes more complex and more connected, cybersecurity is emerging as a major concern, and therefore a priority for development teams.
One standard, in particular, has been developed to address cybersecurity risks in the design and development of car electronics — ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we cover:
An overview of ISO SAE 21434
The urgency behind automotive cybersecurity
How Jama Connect® supports cybersecurity engineering
Introduction
As the automotive industry becomes more complex, and more connected, cybersecurity is emerging as a major concern, and therefore priority, for development teams.
While vehicles have been traditionally isolated systems that had to be physically accessed to tamper with, increasingly, more and more vehicles include wireless connectivity. According to Juniper Research, the number of vehicles with wireless connectivity will rise from 110 million in 2020 to an excess of 200 million by 2025. These vehicles pose a much greater cybersecurity risk than previous designs.
One standard in particular has been developed to address cybersecurity risks in the design and development of car electronics – ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we will examine this important automotive cybersecurity standard, how it is impacting automotive development, and lastly how Jama Software® can help.
What is Automotive Cybersecurity?
Cybersecurity, within the context of road vehicles, is the protection of automotive electronic systems, communication networks, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation.
What is ISO 21434?
Regarded as one of the most comprehensive approaches to connected vehicle cybersecurity, ISO 21434 specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance, and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.
This standard supports the implementation of a Cybersecurity Management System (CSMS).
The first edition of ISO 21434 was published in 2021 and automotive suppliers and OEMs should strongly consider integrating ISO 21434 into their current process.
What is a Cybersecurity Management System (CSMS)?
A Cybersecurity Management System is a systematic risk-based approach defining organizational rules and processes, security policies, resources, and responsibilities to manage risk associated with cyber threats to vehicle road users and protect them from cyber-attacks.
ISO 21434 provides vocabulary, objectives, requirements, and guidelines for cybersecurity engineering in the context of electrical and electronic systems within road vehicles. The goal of the standard is to enable the engineering of electrical and electronic systems to keep up with the state-of-the-art technology and evolving cybersecurity attack methods. Adhering to the standard will allow organizations to define cybersecurity policies and processes, develop a cybersecurity culture, and manage cybersecurity risk.
The structure of the standard is as follows:
14 clauses, 11 are normative
Similar structure and vocabulary as ISO 26262
Each clause has at least one requirement and one work product
Some clauses have RC (recommendations), and PC (permissions)
Nine informative appendixes
Terminology
To achieve the goal of a common vocabulary within cybersecurity engineering for road vehicles, ISO 21434 defines a number of terms.
Asset: A part of an item that has cybersecurity properties (ex: OBD II port, safety requirements)
Attack Path: A series of steps that an intruder could use to compromise an asset
Cybersecurity Goal: Top level product requirement resulting from the TARA (see below for TARA definition)
Cybersecurity Claim: An identified risk that will be accepted, typically mitigated by liability transfer
Cybersecurity Concept: Cybersecurity requirements on the item and operating environment that implement controls to protect against threats
Damage Scenario: The potential damage to a road user caused by the realization of a threat scenario
Item: A component or a set of components that implements a function at the vehicle level. Could be identical to the functional safety item
TARA: Threat and Risk Assessment. Assets with cybersecurity properties are identified and damage scenarios are identified if the asset is compromised. Threat scenarios are identified and supported with attack paths. Risk values are assigned, and cybersecurity goals are established for unacceptable risk
Threat Scenario: Potential cause of the compromise of the cybersecurity properties of one or more assets that leads to a damage scenario
Lifecycle
ISO 21434 defines a cybersecurity lifecycle that starts with the definition of a new vehicle system and ends with that vehicle system being decommissioned or support by the OEM ending.
This means that cybersecurity activities continue after a system is put into production to ensure that new vulnerabilities that are discovered after a system enters production are still identified and mitigations added if necessary.
ISO 21434 defines requirements for an entire organization developing automotive systems to ensure that the necessary cybersecurity governance and culture are in place to support cybersecurity engineering. This includes ensuring that the organization acknowledges that there are cybersecurity risks, executive management is committed to the management of the risks, and that the organization has defined rules and processes to implement the requirements of ISO 21434.
In addition, the organization must have personnel in cybersecurity roles that are competent, policies that define how information can be shared both internally and externally, an appropriate quality management system, management of all product development tools, and robust information security. Audits must be performed to ensure that the organization achieves the objectives.
Project-Specific
Each project that develops or updates a road vehicle system or component must manage the cybersecurity engineering activities specific to that project. This includes the following considerations:
a) Assigning the responsibilities regarding the project’s cybersecurity activities to specific individuals
b) Planning the cybersecurity activities that will be performed during the project
c) Creating a cybersecurity case that provides the argument for the cybersecurity of the system or component
d) Performing a cybersecurity assessment if the project risks deem it necessary
e) A decision of whether the system or component can be released for post-development from a cybersecurity perspective.
In this blog, we define GAMP®5, the framework for a risk-based approach, with an introduction and conclusion provided by Jakob Khazanovich, Medical Device Solutions Consultant at Jama Software®.
What is GAMP®5 and How Does Its Guidance Help Regulated Companies Using Computerized Systems?
When medical product companies decide to implement a new software tool, an important question arises regarding the level of computer system validation required to ensure the latest software complies with regulatory requirements and industry standards.
One major guidance document companies should reference to answer this question is Good Automated Manufacturing Practice (GAMP®5): A Risk-Based Approach to Compliant GxP Computerized Systems.
GAMP® is a set of guidelines for producing quality equipment using the concept of prospective validation following a life cycle model. It was specifically designed by the International Society for Pharmaceutical Engineering (ISPE) to aid suppliers and users in the pharmaceutical industry.
GAMP stresses the use of critical thinking and risk-based assessments to justify the testing approach of a software tool. Its guidelines are widely supported by regulatory agencies and are used globally by regulated companies using computerized systems for compliance and validation.
What is GAMP®5?
GAMP®5 refers to the ISPE’s guidance document, “GAMP®5: A Risk-Based Approach to Compliant GxP Computerized Systems”. This GAMP®5 guide offers a framework for a risk-based approach to computer system validation in which a system is evaluated and assigned to a predefined category based on its intended use and complexity.
Though the steps in this guidance document are not mandatory, the framework provides a comprehensive approach to computer system validation that is generally accepted within the industry.
Based on input from experienced IT, automation, and software practitioners, one of the reasons GAMP® guidance has always been successful is because it reflects the good practices for modern IT and software engineering teams.
Released in July 2022, GAMP® 5 Second Edition prioritizes patient safety and product quality over compliance and encourages the application of critical thinking. The overall GAMP® 5 framework, key concepts, and ICH Q9 aligned Quality Risk Management approach remain unchanged from the First Edition.
GAMP® 5 Second Edition supports standards set for forth by the FDA CDER (Center for Drug Evaluation and Research). Those standards call for “maximally efficient, agile, flexible manufacturing sector that reliably produces high-quality drug products without extensive regulatory oversight, where the vision requires moving beyond simply meeting minimum CGMP standards and towards robust quality management systems.”
This updated version of the guideline aims to help teams meet compliance expectations by offering best practices for IT teams, recommendations for optimal Quality Risk Management approaches, and ways to excel in software engineering, all while achieving better product quality and safety.
Conclusion
The risk-based approach to validation is a best practice seen in guidance documents and used by best-in-class medical industry organizations, many of which are Jama Connect® customers. In general, few tools require full validation but should have functionality confirmed through a subset of tests, the scope of which is determined based on the potential risk to the patient or product.
When your organization implements Jama Connect, consider consulting GAMP®5 guidance to avoid non-value-added over-validation and unnecessary constraints on your processes and systems.
In this blog, we’ll recap our whitepaper, “When Evaluating Product Development Software Tools, Not All Cloud is Equal” – To download the entire whitepaper, click HERE.
When Evaluating Product Development Software Tools, Not All Cloud is Equal
As product development has become increasingly complex to manage across siloed teams and tools, the need for organizations to cost-effectively adapt and scale is increasingly important. Now that over 60% of corporate data is stored in the cloud. cloud-based tools have become mainstream within the engineering function. But the term “cloud” is used by vendors to describe a broad range of capabilities. Before making any software selection, it is important to understand what each vendor means when they say “cloud” and how to compare them.
The Different Types of Cloud Deployment Models: A Quick Primer
There are three types of cloud deployments: public, private, and hybrid.
Public Cloud: A public cloud infrastructure is managed by a cloud provider, and many companies use the same cloud provider. Public cloud offerings are often multi-tenant, meaning your application(s) is hosted alongside those of other companies; however, data is kept separate and secure. Some applications you might already use that leverage a multi-tenant cloud include Microsoft Outlook and Microsoft 365. Amazon Web Services (AWS) is the market share leader of public cloud providers.
Private Cloud (Outsourced Hosted): A private cloud is outsourced hosting of the application to a 3rd party. The outsource provider hosts and manages the application without the advantages of cloud architecture for scalability, high availability, security, and cost effectiveness. This approach is typically the most expensive and requires the most thorough security assessment. Often, software vendors who do not have the expertise to provide cloud hosting will outsource the hosting to their partners.
Hybrid Cloud: A hybrid cloud is a computing environment using private and public clouds and allowing applications and data to be shared between them.
Non-cloud deployment model:
On Premises (Self-hosted): A company chooses to host and manage the application themselves in their own environment. This approach is more expensive and requires the most internal resources.
Single Tenant vs. Multi-tenant Clouds: What’s the Difference?
94% of enterprises use cloud applications and the majority of their data is already in the cloud1. Here are a few important differences when comparing single-tenant with multi-tenant clouds.
Single-tenant cloud
With a single-tenant cloud you have a single instance of the software application meant to be used by your business. A single-tenant cloud is like running the application on your IT department’s hardware on-premise, but since it operates in the cloud, you’re using the provider’s infrastructure.
The drawbacks of a single-tenant cloud
Vendors that are unable to offer a multi-tenant cloud often try to scare companies away from multi-tenancy by saying it is not as secure. Of course, the entire modern economy is running on multi-tenant cloud systems from email, collaboration, task management, CRM, banking, and financial transaction systems. The need to physically separate data for security has long been solved by logically separating data and sharing databases. A multi-tenant cloud is actually more secure than a single tenant cloud against any external intrusion since it has two layers of security within the cloud environment instead of just one. Additionally, there are significant costs and risks by refusing the benefits of multi-tenancy:
Setup is complicated. A single-tenant cloud sets up a deployment stack for every customer. The provider’s burden is multiplied by every customer, making operations inefficient and error-prone since each tenant must be handled individually. The multiplicative effect increases the risks of mistakes, configuration drift, and maintenance burden.
The cost is high. Operating a single-tenant cloud is more expensive than the multi-tenant alternative since it requires a dedicated deployment stack that must be 100% paid for by the customer even when processing time and storage are not utilized.
Resources aren’t optimized. With a single-tenant cloud, you aren’t fully utilizing your resources, often leaving computing power — and money — on the table. As a result, you lose the ability to share costs for things like system monitoring, serviceability, and deployment.
Scaling is not an option. With a single-tenant cloud, you lose the ability to scale up or down resources as you need them.
More complex backups, restoration, and disaster recovery. Backing up and restoring become a stack-by-stack operation that must be managed and validated individually. In the event of a disaster, there’s no telling where your instance ends up on the priority list since they must be restored one at a time. This option also creates a single point of failure.
Here are the main benefits of a multi-tenant cloud:
Lowers your costs. A multi-tenant cloud allows the provider to leverage economies of scale. Operations, maintenance, upgrades, and scaling are done across the infrastructure base instead of one at a time. Things like backups, disaster recovery, and upgrades become simple, single operations instead of thousands of checklist-style work items. This reduces the multiplicative risk of individual operations and lowers the overall total cost of ownership (TCO).
Uses resources more efficiently. A single-tenant cloud often leaves extra resources on the table. And since you’re paying for all of it whether you use it or not, excess computing power is wasted. A multi-tenant cloud allows you to use only what you need and pay less to access it.
Gets you up and running faster. Getting up and running fast is important whether you’re a large enterprise, a smaller business, or a start-up. A multi-tenant cloud helps you quickly scale up or down to maximize resources.
Completing updates is easier. A multi-tenant cloud handles all your upgrades and updates, so you are free from disruptions and the additional costs associated with staying current.
Backups and restoration are simplified. A multi-tenant cloud backs up relevant data and resources, supporting business continuity and resilience planning.
Key Considerations When Choosing a Cloud-Based Engineering Tool Provider
What is the uptime service level agreement (SLA)?
Cloud-based software providers should be able to report their uptime at any given time and show the history of the uptime over a year.
Jama Software® publicly shows our cloud status on a minute-to-minute basis at status.jamasoftware.com
Does the provider operate in a high availability environment?
It’s not enough to have your application hosted in a major cloud (AWS, Azure, GC), the provider must design their infrastructure to be fault tolerant and adaptable to different failure scenarios.
Cloud software providers like Jama Software® provide a cloud architecture diagram that shows fault tolerance and no single point of failure.
How does the provider protect you in the event of a disaster?
While cloud services are incredibly robust, things do happen! A fully documented, tested, and validated disaster recovery plan is essential to any cloud software provider’s continuity of service.
Jama Software has a disaster recovery plan that specifies RPO and RTO objectives and it is tested at least annually in a production environment scenario
What security guarantees does the cloud software provider make?
While the underlying cloud infrastructure is incredibly secure, the software provider must take steps to secure their application. Static and dynamic scans, PEN tests, and cloud best practices (OWASP) all play a role in securing the software and your data.
At Jama Software we take security seriously and protecting our customers’ data is our highest priority. We code with Open Web Application Security Project (OWASP) best practices, host in a secure AWS cloud, perform daily static and dynamic scans, PEN test (third-party) twice a year, and are in the process of our SOC 2 Type 2 audit. Once the audit is complete, we will be the only requirements management platform on the market with a SOC 2 Type 2 certification.
![[Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)](https://www.jamasoftware.com/media/2023/04/BLOG-RECAP-Medical-Device-Webinar-Social-Image.png "[Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)")
![[Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System](https://www.jamasoftware.com/media/2023/03/Cybersecurity-Risk-RM-.png "[Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System")
