Tag Archive for: Requirements & Requirements Management
2025 Expert Predictions for the Semiconductor Industry: Innovations, Sustainability, and Globalization
The semiconductor industry is navigating a transformative era, marked by groundbreaking innovations and pressing challenges. As AI and machine learning demand faster, more efficient chips, semiconductor design and manufacturing are evolving at an unprecedented pace.
In part three of our annual predictions series, Michael Luciano, Senior Account Executive at Jama Software, explores the key trends shaping the industry. From advancements in silicon photonics and memory technologies to innovations in cooling systems and power delivery, these developments are poised to revolutionize chip performance while addressing critical energy efficiency needs.
Michael also addresses growing concerns about the environmental impact of chip production. With the immense power demands of AI-driven data centers and the continued use of harmful chemicals in manufacturing, the industry is turning to nuclear energy, novel materials, and refined processes as potential solutions. Emerging markets like India and China also play a pivotal role in future growth, highlighting the importance of global collaboration and infrastructure investment.
We like to stay on top of trends in other industries as well. Read our predictions for Industrial & Consumer Electronics (ICE) HERE, and Automotive HERE – Plus, stay tuned for future topics, including Aerospace & Defense, Medical Device & Life Sciences, and AECO.
With AI and machine learning driving demand for faster, more efficient chips, what key innovations in semiconductor design do you predict will transform these technologies, and how can companies balance performance with energy efficiency?
Michael Luciano: This is a great question. Key innovations in semiconductor design coming from increased demand with AI and machine learning (ML) will likely be on-chip optical communication using silicon photonics, continued memory innovation (i.e. HBM and GDDR7), backside or alternative power delivery, liquid cooling systems for Graphics Processing Unit (GPU) server clusters and superclusters.
Do you have any concerns or anticipate any negative impacts as it pertains to AI & ML?
Luciano: It’s understandable that people have concerns. Like every other tool that man has created, it’s important to create safeguards to prevent misuse and abuse. Agreeing on the exact safeguards and corresponding regulations is a highly contested and complex topic with wildly ranging global opinions. It’s undeniable that as AI systems and tools continue to evolve, these systems will replace some people’s jobs. This is already starting to happen. I am cautiously optimistic. As AI technologies become more advanced, with every negative impact I believe there will be an equal or greater level of positive impact for society and mankind elsewhere. Artificial superintelligence (ASI) is a hypothetical AI system with an intellectual scope beyond human intelligence. Mankind needs to see eye-to-eye before ASI comes to fruition or we are all in trouble. But don’t worry, we still have some time.
As chip production faces increased scrutiny for environmental impact, what role do you see for sustainable materials and manufacturing practices in the semiconductor industry, and how can software contribute to optimizing these efforts?
Luciano: In the context of the AI boom – the power required to operate gigawatt+ data centers is immense. Nuclear power is likely the most environmentally friendly way to go about it. Amazon and Google are currently investing heavily and recently formalized several key partnerships in this space. In the context of individual chip/device manufacturing – modern fabs also require a lot of energy/power. Nuclear powered systems will be the long-term answer. There are also a lot of nasty chemicals and gases that are used in chip production. I don’t see a clear way to fix this now, but as academia continues to study alternatives and companies continue to invest heavily in Research and Development (R&D) there is a possibility individual process steps can be adjusted/refined to incorporate novel materials or find other ways to help mitigate detrimental environmental impacts.
As the semiconductor industry becomes increasingly globalized, what emerging markets or regions do you see as pivotal to future growth, and how can companies foster effective cross-border partnerships and innovation?
Luciano: I identify Asia-Pacific (APAC) as the largest emerging market – specifically India and China, due to their populations. Companies can foster effective cross-border partnerships and innovation through significant investment in key infrastructure in those markets.
Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?
Luciano: AI Agents will mature and become widely used. This will significantly change how companies operate and go-to-market (GTM.)
https://www.jamasoftware.com/media/2024/12/2024-12-19-predictions-Semiconductor-2025.png5121024Jama Software/media/jama-logo-primary.svgJama Software2024-12-19 03:00:232024-12-20 12:30:022025 Expert Predictions for the Semiconductor Industry: Innovations, Sustainability, and Globalization
In this blog, author Vincent Balgos discusses the 2024 MedTech Conference, which took place in Toronto, CAN, from October 15 – 17, 2024.
Shaping the Future of MedTech: Insights from Industry Leaders on AI, Innovation, and Regulatory Challenges
Jama Software made its debut appearance at 2024 MedTech Conference in Toronto, CAN recently, and it was an inspiring experience. In addition to meeting passionate medical technology developers, learning the latest innovation trends, and establishing networking connections, I had the opportunity to attend a few panels/talks that wanted to share some insights.
Keynote: Medtech in Motion: Shaping the Future of Health Care Innovation
Attendees (left to right) Peter Arduini – President & CEO at GE Healthcare; Mike Mahoney – Chairman & CEO at Boston Scientific; Roy Jakobs – CEO at Philips; and Joanne Wuensch – Moderator.
With the keynote introduction and brief overview of med tech evolution provided by by AdvaMed’s President, the main event was a panel of Chief Executive Officers from GE Healthcare, Boston Scientific, and Philips discussed key factors that are forging the path of industry innovation.
Artificial Intelligence’s (AI) continual emergence in the conversation of innovation with application for both internal and external purposes. On the external side, AI’s predictive approach is a dominant talking point, supporting medical professionals on complex data analytics by identifying trends, correlations, etc., to help inform clinical decisions at scale. On the internal application, generative AI technology was mentioned as a potential factor to streamline efficiencies with improved internal processes and workflows within the organization. This is a topic that both AdvaMed President and GE Healthcare CEO have previously posted about, highlighting AI’s benefit on both the external and internal fronts that is already reaching patients’ bedsides and company’s processes (respectively) now. These tech-enabled efficiencies are proving to be a potential game changer in the way medical devices operate and develop products. An interesting un-answered question is the integration of AI into an ecosystem of tools, processes, and products, and its impact on the overall value.
The CEO panel unanimously agreed that removing bottlenecks, reducing inefficiencies, and leveraging automation are key for continual innovation in the med industry. With resources becoming limited and the complexity of technology increasing, there’s a continual search for innovative ways to develop safe and effective products faster. To paraphrase, any efforts to allow the development team to focus more on development activities and automate the routine, mundane tasks such as documentation provide teams more time to do the more challenging tasks.
Looking forward five years from now, the discussion turned to how to balance the fast innovation trend seen in emerging/non-traditional markets and the safety and effectiveness performance expectations of the medical industry.
Is there a way to harmonize both to develop safe products, but at accelerated velocity?
Also, how will regulations keep up with the pace of innovation, especially AI?
While FDA proactiveness is helping guide the industry, there are still a lot of unknowns that need to be discovered, derisked, and regulated appropriately.
On the second bullet, Jama Software can support the acceleration of development processes by streamlining the requirements, verification/validation, and risk management all within a single tool. By leveraging the out-of-the-box solutions, traceability to quality best practices becomes an automated byproduct, where can easily create technical documentation at the push of a button. By making routine documentation activities routine, developers can then focus on the more challenging aspects of product development, thereby increasing the velocity and efficiency of innovation. To learn more, please contact us.
Attendees (from left to right) Janet Trunzo – Moderator; Dr. Michelle Tarver – FDA Office of the Center Acting Director; Dr. Jeffrey Shuren – FDA Office of the Center Director; Dr Daniel Canos – Director, Office of Clinical Evidence and Analysis; Dr Owen Faris – Director, Office of Product Evaluation and Quality; and Troy Tazbaz. – Director, Digital Health Center.
Pictured (from left to right) Dr. Michelle Tarver – FDA Office of the Center Acting Director; Dr. Jeffrey Shuren – FDA Office of the Center Director.
What better way to start the last conference day than having breakfast while listening to the FDA Center of Radiological Health (CDRH) panel sharing some of their leading thoughts on trending topics within the industry. With introductions by Terumo CEO and announcing the upcoming retirement of Dr. Jeff Shuren (Director). Next was the introduction of Dr. Michelle Tarver as the incoming Director, where Dr. Tarver gave an introductory speech, highlighting her focus on a patient-first approach, providing access and equity to safe and effective medical devices to general population, and her visions for continuing and evolving FDA’s path for regulatory guidance for industry, including the Home as a Health Care Hub initiative.
After the panel introduction, the audience was encouraged to ask questions. Some (paraphrased) questions and responses are below:
[Editor’s Note: These responses are paraphrased from the FDA and not actual FDA statements. Please also note that Jama Software is not a regulatory consultant. These are observations only.]
How is FDA providing medical care access to more underserved patient population, particularly the women population?
Response: One of the key strategic priorities for CDRH in 2022-2025 is advancing heath equity for all patients and evaluations that take into account is the diverse population for which they are intended.
Jama Software: After the conference, an online search resulted in an Executive Summary for more information. Referencing the introductory speech, Home as a Health Care Hub seems to be a key factor in broadening all patients’ access to healthcare.
How does industry streamline their submissions processes and success rate to the FDA? It is very costly to the organization for each resubmit & re-address cycle.
Response: Before formal submission, it is highly recommended to consider pre-submissions as part of the regulatory strategy. This allows early interactions between FDA and the organization to help answer questions, identify gaps in the submission, and provide general guidance for a successful pathway.
Jama Software: Based on my experience, pre-submissions are standard of practice to help derisk many unknowns and help successfully navigate through the complicated submission process, especially with novel technologies or indications of use scenarios. I’d consider FDA as more of a partner than “overlord” as they have the shared goal of providing safe and effective medical to US patient population. If done correctly, pre-submissions save organizations time and money, since many of the questions / issues are proactively addressed.
While the FDA has been proactive in providing regulatory guidance on Artificial Intelligence development and applications, there are still many open questions, especially in generative AI and post market scenarios. What are some key areas that are in discussion (e.g., validation of generative AI)?
Response: Generally acknowledged that there is a lot to still discuss since it is an evolving technology. The 2023 draft guidance on “Marketing Submission Recommendations for a Predetermined Change Control Plan fo Artificial Intelligence/Machine Learning (AI/ML) – Enabled Device Software Functions” provides some considerations in how to manage change, especially in the post-launch scenarios. Since GenAI is continually learning and adapting to new data, there will be focus on post-market topics and how to handle AI’s dynamic state. This includes validation strategy and some general guidance. In addition, some general questions for organization to consider during AI development are:
What are the general problem statements that AI is trying to solve?
What are the large language models (LLM) being used for the device? Does the LLM support the devices intended use case(s)? Or is it the rationalization part of AI that is assessing data?
Would a separate AI be needed to monitor / manage the device’s AI?
Defining these approaches may help understand the associated benefits and risks with these new devices.
Jama Software: Previous FDA documents (1, 2) also shed some light on what the regulatory framework could look like in the future, so encourage research and comprehensive documentation of AI’s software requirements, testing, and associated risks.
Overall, breakfast with FDA was an insightful experience to understand what the regulatory body is thinking around current topics. When it comes to complex medical device development, Jama Software can support regulatory and quality compliances to key standards (Design Controls, ISO 13485) to allow teams to streamline their work efficiencies, reduce rework, and accelerate product launches to market.
To go faster, what tools and processes can be used to automate the more mundane tasks?
Digital Health Coverage is Limited
The regulators and industry are still trying to catch up. This is why hospitals are getting attacked, breeches, etc. Software is becoming more and more prominent, plus the software with connections introduces a huge vulnerability for bad actors. We’re still trying to wrap our heads around this. Final guidance on cybersecurity was released in 2023. There must be a cybersecurity plan included in your final submission.
Faster is Not Always Better
Unlike consumer electronics or social media, medical device & life sciences industry likes innovation, but having the latest innovation is not always great – the tradeoff is reliability, safety, and effectiveness. Just because you CAN go faster with innovation and development time, doesn’t mean you should. Because we deal with patients, we have to keep quality in check. We need to take a more thoughtful, steady, and proactive approach. If we don’t understand the software, we are putting a lot of our patients at risk.
Longitudinal Thinking and Applications
The CEO of GE and Philipps mentioned this twice in their speech. In this area, they want to have longitudinal traceability OUTSIDE of the device – worrying about the infrastructure, the users, the medical records, and other aspects of the product or the organizations. The impact isn’t on my device, there’s a broad impact.
In your submissions, in terms of cybersecurity, you must have good documentation. Define your problem, what are your indications of use, what is your environment of use (is this a connected device, where are the digital connections and vulnerabilities). What the FDA is looking for is a story to take a more risk-based approach to developing and approving products.
In medical device development, we used to have this thought: If you’re not sure of something, go back to the documentation. Trust it but verify it.
The new thinking is that you should never trust it and always verify. Documentation is becoming more complex, and teams sometimes aren’t documenting in the way that they should.
https://www.jamasoftware.com/media/2024/12/2024-11-08-shaping-future-of-medtech-conference-recap-1.jpg5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2024-12-17 03:00:222024-12-17 09:36:22Shaping the Future of MedTech: Insights from Industry Leaders on AI, Innovation, and Regulatory Challenges
2025 Expert Predictions for the Automotive Industry: AI, Sustainability, and the Road Ahead
The automotive industry is undergoing a seismic transformation, driven by advancements in AI, machine learning, electric vehicles, and sustainability initiatives.
In part two of our annual predictions series, Jama Software’s industry experts — Neil Stroud, General Manager of Automotive & Semiconductor; Stefan Stange, Managing Director; Matt Mickle, Director of Solutions and Consulting; and Ádám Gősi, Account Executive — share their insights on the most pressing challenges and groundbreaking innovations shaping the future of automotive.
From the rise of software-defined vehicles to overcoming supply chain disruptions and achieving ambitious sustainability goals, this year’s predictions offer a compelling roadmap for manufacturers looking to stay competitive and thrive in the years ahead.
We like to stay on top of trends in other industries as well. Read our predictions for Industrial & Consumer Electronics (ICE) HERE and stay tuned for future topics, including Aerospace & Defense, Medical Device & Life Sciences, Energy, and Semiconductor.
Question 1 – With the rising integration of AI, machine learning, and autonomous systems, how do you foresee these technologies reshaping automotive and semiconductor operations? What are the most promising applications and potential challenges?
Neil Stroud: The industry has undergone somewhat of a reset of expectations around autonomy. Solving the challenges related to autonomous vehicles is harder than we all thought. Generally, we are now laser-focused on the software-defined vehicle and developing the related systems that allow mass deployment of L2+ and L3 capable vehicles. This will ultimately lead into autonomy anyway.
It’s great to see robotaxi solutions gaining traction with L4 (ODD limited L5) and humans slowly becoming more open to getting in a vehicle with no driver. This is a massive mindset shift.
AI/ML has a massive role to play in all of these areas.
Stefan Stange: Development complexity and quality expectations will increase exponentially while the development time and cost must decrease, modern tools and processes supported by AI will support to solve these challenges.
Matt Mickle: With automotive, AI is exponentially increasing the development of systems that will enhance safety, enable convenience, and make maintenance more reliable. Overall, this is shifting the perspective of the driving experience entirely. This does come with concerns around risk especially in regards to cybersecurity, and with ethical decision making.
On the semiconductor side AI is helping to optimize design of chip architecture and enhance performance with AI-assisted tooling providing better analytics. Risks here are also in cybersecurity as well as supply chain risks due to things like export controls and potential tariffs.
Ádám Gősi: The challenge I think will define future development is intellectual property and how certain tools and models are handling sensitive data. Besides this, it is important to establish the responsibilities. In safety-critical development there always has to be a human expert to control the result. These factors will determine if it is worth investing in developing a new AI model or maybe adopting an existing one. Customers often don’t have their own definition of what they are expecting of an AI, they expect us to show them our best interpretation so far. This could lead to a trap of over-promising. With my limited knowledge, I see the current era as the “gold rush era” – some AI developers don’t have a clear target just hoping to hit the big prize.
Question 2 – As a follow-up question: Do you have any concerns or anticipate any negative impacts as it pertains to AI & ML?
Stroud: As someone who has worked in functional safety for almost 20 years, I’m still concerned about the industry’s ability to develop systems that have the appropriate levels of safety where AI is involved. As humans, we expect the autonomous world to be a safer world and reduce the number of accidents, injuries, and deaths on our roads. However, there are plenty of high-profile examples where we are falling short.
Stange: Safety and security are a must, not losing the data authority.
Mickle: Definitely many concerns with things like AI being used maliciously in cybersecurity attacks, Energy consumption and waste issues due to the massive amounts of computational energy needed, unpredicted failures or AI hallucinations, etc. but these need to be considered and worked through as progress is inevitable and unavoidable.
Gősi: In safety-critical development there always has to be a human expert to control the result.
Question 3 – With the rapid progression toward electric vehicles (EVs) and autonomous driving, what technological advancements do you think will be critical to automotive innovation over the next few years, and how can manufacturers stay competitive?
Stroud: The industry has to keep investing in battery technology to increase the range capabilities of vehicles as well as extending useful battery lifetime. It will be interesting to see how well alternative fuels such as hydrogen become mainstream. I do think there will be new data that comes to light that shows that electrification isn’t necessarily the holy grail that we expect. Building batteries is taking a major toll on the planet so there may well still be a combustion engine resurgence. Also, there is a macroeconomic challenge in that 80% of the world EV batteries come from China.
There is also a significant electrical grid infrastructure challenge to solve that is hugely expensive. As the number of EV’s grows, it will be theoretically possible to intelligently use power stored in unused vehicles to supplement the grid for supply. However, the grid we have today is fundamentally unidirectional (i.e. power station to consumer). Making this bidirectional is a massive and costly challenge.
Over the coming years, there is no doubt the industry will continue to get autonomous operation to a more reliable, safe, and therefore more mass-deployable state. As a result, new car ownership and usage business models will emerge enabled by technological advancements.
Stange: Development complexity and quality expectations will increase exponentially while the development time and cost must decrease. The use of modern and forward-thinking solutions will help.. Defining and following reliable processes and partnerships enabling a collaboration network by using best-in-class solutions with full traceable Agile for the development and manufacturing process should be the goal.
Mickle: AI has been coined as the next major platform shift or technology super cycle and will be the primary change for the upcoming years until we have greater machine intelligence or perhaps “machine consciousness” or Artificial Super Intelligence where AI actually outperforms humans across the board.
Gősi: As release cycles are ever shorter, products and software have to be released before fully developed. Over-the-air updates will be an important factor. Automakers will be able to update less developed rapidly depreciating models. ADAS sensors will become more refined, but incrementally. The current hardware is capable of fully self-driving. Software and regulation/local law are the limiting factors. Battery technology could see an improvement in general with the range increasing. Western Manufacturers will have to bring down the costs and improve on software quality, like Asian EV manufacturers.
Question 4 – Sustainability is a growing focus in the automotive industry. How do you see product design, materials, and manufacturing processes evolving to meet environmental goals and what role will software play in supporting these sustainable initiatives?
Stroud: There are many aspects to this. Making vehicles even more recyclable is fundamental. This impacts not only the materials used within the vehicle but also the design and construction of the vehicle. There is always the tradeoff between the value of recycled materials versus the cost of the effort to break the old car down into distinct recycled parts.
We are already seeing huge effort being put into efficient scalability and reuse when it comes to vehicle chassis platforms and software reuse.
Finally, manufacturing has a key role to play. The continuous march towards the truly smart factory that not only allows for mass-customization but also the ability to manufacture multiple models on the same production line even to the point where a single MaaS line can produce for multiple OEMs. These megafactories will be super-efficient and because there are fewer of them, the environmental impact will be lower.
Stange: The complexity also to guarantee sustainability will increase and must be handled with a professional and scalable software and process.
Also, the market expectation in regard to design, materials, individuality and related manufacturing processes will increase and be a game changer for success.
Mickle: Systems are being designed more with an end of life in mind and with reusability and modularity as a backbone. We’ve seen this shift for many years now with SDVs and it will only grow. Data provided by AI driven software will help drive optimization in the lifespan of all areas of the development process and supply chain, enhancing efficiency to reduce waste and understand better how things can be reused.
Gősi: Sustainability goals are not supporting the real cause in my belief. If EVs are going to continue being the supported trend by governments, and therefore manufacturers, then the battery manufacturing and recycling process needs to be improved to be more sustainable.
Question 5 – As software-defined vehicles become the new standard, what shifts do you anticipate in software development and cybersecurity practices to support seamless updates, driver experience, and vehicle safety?
Stroud: Software is eating the world. The challenges faced by OEMs in the software domain is immense. The modern vehicle contains hundreds of millions of lines of code. More than a modern commercial or military aircraft. This problem is compounded as the software comes from hundreds of third-party vendors and it is the responsibility of the vehicle manufacturer to integrate and test everything for correct operation and ensure it is still safe, secure and performant. This need must drive a mindset shift in the way systems are designed as well as breaking down the barriers between the OEM’s and the suppliers. The ones that will succeed are the ones that foster seamless interfaces between organizations. This will directly impact safety and security in a positive way as well as accelerating innovation.
Stange: A car becomes more and more a computer with wheels with exponential increase of requirements regarding software, updates on weekly basis also considering cybersecurity. Manufacturers have to balance between cost and security and develop cars that allow access to like a iPhone or computer but with higher and better security and safety strategies.
That means, car software platforms have to change and improve dramatically in the next years.
Mickle: Increased automation and traceability throughout the toolchain, using AI to analyze data and improve efficiency by providing that data intelligently to influence rapid change and execution.
Gősi: On the high level over the over-the-air updates and software updates and development need to be improved at the majority of OEMs and suppliers.
Question 6 – How is the automotive industry preparing to address challenges in the supply chain, particularly with semiconductor shortages, and what strategies could help improve resilience and adaptability in the face of future disruptions?
Stroud: The recent semiconductor supply constraints were a wakeup call for the industry. Vehicle shipments were being held up because of the lack of availability of the smallest sub-$1 components. As a result, I see two behaviours emerging. Some OEM’s are naturally building strategic partnerships with the semiconductor suppliers and trying to contractually guarantee supply. This gets interesting as the majority of semiconductor companies are ‘fabless’ and rely on companies such as TSMC, Global Foundries and SMIC. The other strategy is to take matters into your own hands and develop your own chips (ASIC) that provide exactly the functions that are needed versus the inevitable compromise that often happens with an off-the-shelf standard product. Companies like JLR are starting down this path. However, it’s not for the faint-hearted. Chip design is not easy and it’s expensive especially if you want to gain the benefits of the latest bleeding edge process nodes. Also, you will still be dependent on the same fab companies that serve the rest of the industry.
Stange: I see OEM collaborating more and more with start up´s in the semiconductor or EV market to assimilate the needed know how, strategies and flexibility reacting fast to the market needs. So, for example VW collaborates with Rivian and announced using their Software platform for the next Audi´s and VW´s and Aston Martin is collaborating with Lucid.
Mickle: Investment in local suppliers as well as diversifying the regions from which supplies are acquired. Also designing for flexibility and modularity such as with chiplets.
Gősi: Shortages don’t seem to be a problem nowadays. The supply chain needs to be more agile and detect risks sooner to avoid the delays caused by the JIT method.
Question 7 – The concept of “mobility as a service” is gaining traction in urban areas. How do you think automotive companies should adapt to this trend, and what new types of partnerships or innovations do you foresee in this area?
Stroud: MaaS will ultimately drive massive change in the way the mobility of the population happens. We already see that the current generation generally has a dramatically different view on driving and vehicle ownership. We’ve already witnessed the disruption that rideshare created. The car OEMs will have to adapt and develop new business models that go beyond the traditional purchase and lease models of today. There will be intermediary companies that emerge (that could be subsidiaries) that provide such services. I also envisage tighter integrations with the insurance companies as the volume of individual vehicle data that’s available will allow for hyper-tailoring of such services.
Stange: From my perspective, we have started mobility as a service already in urban areas with apps like FreeNow or Uber and more will come. Important is, that everything somehow has to be networked with the support of intelligent systems and software.
Also, the infrastructure, for example, intelligent charging points, parking, and availability has to improve. The way of thinking about mobility as a service has already changed for the younger generation, while my older son still likes cars for fun and as a status is my younger son just considering how to get from A to B fast, cheap, and safe.
Gősi: This is a business question between OEMs and local governments. From a product perspective, they would need cheap-to-produce and cheap-to-maintain and easy to drive vehicles that can serve those users. Manufacturers will have to further optimize their platform strategy for this specific application.
Question 8 – Are there any additional insights you have regarding predictions, events, or trends you anticipate happening in 2025 and beyond?
Stroud: I strongly believe that it is not the technology that will limit the deployment of these new technologies but the legislation. Every single country has a different set of rules and that will have a significant impact. We also have to overcome the challenges of dealing with ethical AI. Autonomous crash scenarios will have to be ‘calculated’ differently depending upon geographic location. Naturally, this is a highly sensitive topic but one that must be solved.
Stange: 2025 will be a challenging year for Automotive specially and Europe, unclear EV strategies, Asian competition, high taxes, energy and labor costs, and political struggles – everything will push the auto industry to slimline their way of thinking, developing, and manufacturing. On the other side, there will be a lot of opportunities for the innovators, the startups, and the companies, that reinvent themselves and restructure in a healthy way, these are the ones, we are happy to support.
Gősi: Unless there is a major shift in strategy and execution, the traditional European OEMs will lose their market-leading position. Innovative US and innovative and competitive Asian manufacturers will take over the leading position.
Editor’s Note: Responses reflect a mix of British and American English, depending on the respondent.
https://www.jamasoftware.com/media/2024/12/2024-12-12-predictions-automotive-2025-1.jpg5121024Jama Software/media/jama-logo-primary.svgJama Software2024-12-12 03:00:592024-12-18 14:17:572025 Expert Predictions for the Automotive Industry: AI, Sustainability, and the Road Ahead
Jama Connect® Features in Five: Jama Connect Interchange™ – Universal ReqIF Import
Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.
In this Features in Five video, Mario Maldari,Director of Solution Architecture at Jama Software, will introduce viewers to the Jama Connect Interchange universal ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined.
VIDEO TRANSCRIPT
Mario Maldari: Hello. My name is Mario Maldari and I’m the Director of Solution Architecture here at Jama Software. Today, we’ll be discussing the Jama Connect Interchange Universal ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined. With Jama Connect Interchange’s Universal ReqIF file-based exchanges are simple and streamlined regardless of what requirements management tool is used by the supplier. The tool’s automatic and intelligent field mapping helps to facilitate a smooth import process ensuring all data comes into Jama Connect as expected. This includes field and data mapping as well as maintaining upstream and downstream traceability between various requirements. Let’s explore how this works with Jama Connect Interchange.
We have received a ReqIF export from one of our many suppliers. This particular file contains a mixture of system requirements and subsystem requirements. We have worked with our supplier to define fields and values for the requirements. The system requirements contain tolerance values and due dates that were set in the originating tool. It also has subsystem requirements that contain a Boolean value named Compliance, which is set to true or false. We’ll be using Jama Connect Interchange to create a conversation, map our attribute fields, and import into Jama Connect.
Maldari: The first thing we will do is to create a conversation that will define the context of the import. We will choose a Jama Connect project that we would like to import the ReqIF file into and provide a name for the conversation so that we can refer back to it at any time to perform additional imports or exports. Once completed and saved, we can select on the Import tab. This is where we will upload our ReqIF file and prepare for the import. We can select a location in the Jama Connect project for where we want the requirements data to be imported into. We will create a simple mapping of the requirement types found in the ReqIF file to the desired and corresponding requirement types in the Jama Connect project.
Once this is achieved, we can point and click to map our labels and attributes. First, we’ll map the labels for our system requirements. One of the great things about Jama Connect Interchange is that it automatically detects the type for you during the upload process, so that you can easily perform a corresponding mapping into Jama Connect. This helps save time during your imports. It also takes the guesswork out of manual mapping. In this case, we’ll map four values, name, description, tolerance, and due date. The field mapping can easily be toggled on or off, depending on the data you want to map and import. Next, we will map the labels for our subsystem requirements. In this case, we’ll also map three values, name, description, and compliance.
Finally, we want to ensure that whatever relationships and traceability that existed in the source system are mapped over when imported into Jama Connect. Let’s go ahead and include the relationships, and we can even select the relationship type that we would like the requirements to have when imported. Once our desired mapping is complete, we can click the Initiate Import button to begin the import process. In this case, we’ll create new items. However, if we’re performing a round-trip exchange and we had already imported, we can easily update the items with changes made by our supplier during the import process. All events are logged in Jama Connect Interchange so that it’s easy to check on status and progress. Let’s navigate over to our Jama Connect project to see the imported requirements.
Maldari: As expected, we see both system requirements and subsystem requirements. We can take a look at each and verify that the name, description, and other fields such as tolerance and compliance have also come in populated with data. We can view the relationships in traceability using our trace view to ensure that the traceability from the source system has been maintained. We can easily modify any of the values in these fields and change them according to our working process in normal requirements management activities. We can continue elaborating these requirements in Jama Connect or export them using Jama Connect Interchange to share back with our supplier at any time. Many requirements’ management tools have implemented their own version of ReqIF making interoperability a challenge. Only Jama Connect provides interoperability with universal ReqIF, making imports and exports easy regardless of their originating source.
Thank you for watching this Features In Five session on the Jama Connect Interchange for ReqIF import. If you’re an existing customer and want to learn more, please reach out to your customer success manager or consultant. If you’re not yet a client, please visit our website at Jamasoftware.com to learn more about the platform and how we can help optimize your development process. Thank you.
https://www.jamasoftware.com/media/2024/12/JCI-ReqIf-2.jpg10801920Mario Maldari/media/jama-logo-primary.svgMario Maldari2024-12-06 03:00:332024-12-05 15:02:55Jama Connect® Features in Five: Jama Connect Interchange™ – Universal ReqIF Import
In this blog, we’ll recap a section of our eBook, “Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects” – Click HERE to read the entire thing.
Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects
The oil and gas industry is a cornerstone of the global economy, but it faces a growing set of challenges in an increasingly complex and competitive landscape. From fluctuating market dynamics and stringent
environmental regulations to technological advancements and the demand for operational efficiency, companies in this sector must navigate a series of critical obstacles to remain resilient and sustainable.
In this eBook, we explore the top challenges shaping the future of the oil and gas industry, providing insights into how businesses can adapt and thrive amid these shifting pressures.
Energy Transition and Decarbonization
The global shift toward clean energy and reducing carbon emissions poses a significant challenge for oil and gas companies. The pressure to decarbonize operations, meet regulatory standards, and invest in renewable energy sources is growing. Balancing the need to reduce greenhouse gas emissions while maintaining energy supply and profitability remains a key issue.
Investment in carbon capture, utilization, and storage (CCUS) technologies is becoming crucial for oil and gas companies as they seek to reduce their carbon footprints while continuing operations. CCUS can help mitigate the environmental impact of fossil fuel production by capturing CO2 emissions before they are released into the atmosphere. Additionally, oil and gas companies are increasingly expanding into renewable energy sectors like solar, wind, and hydrogen to diversify their portfolios and align with global efforts to decarbonize energy. Navigating complex carbon regulations, such as emissions trading systems and carbon pricing, also requires strategic planning to minimize costs while meeting government and international compliance targets.
KEY CONSIDERATIONS
Investment in carbon capture, utilization, and storage (CCUS) technologies.
Expanding into renewable energy sectors like solar, wind, and hydrogen.
Navigating complex carbon regulations and pricing mechanisms.
Volatile Market Conditions
The oil and gas market is highly sensitive to global political, economic, and environmental factors. Fluctuations in oil prices due to geopolitical tensions, supply chain disruptions, or demand fluctuations (such as those caused by pandemics or global economic shifts) can severely impact profitability and investment planning.
Geopolitical risks, such as conflicts in oil-producing regions or shifts in international relations, can lead to sudden and significant fluctuations in oil prices. This volatility is further exacerbated by disruptions to global supply chains, economic recessions, and unpredictable demand patterns due to factors like pandemics or rapid changes in energy consumption behavior. Oil and gas companies must remain agile, continuously assessing market conditions and adjusting their production strategies accordingly. Managing these fluctuations requires strong financial risk management, flexible supply chains, and forward-thinking strategies to hedge against market downturns.
KEY CONSIDERATIONS
Geopolitical risks, such as conflicts in oil-rich regions.
Supply and demand imbalances.
Economic slowdowns affecting global oil consumption.
Technological Innovation and Digital Transformation
As the industry evolves, there is increasing pressure to adopt new technologies that will improve operational efficiency, safety, and sustainability. The integration of digital tools like artificial intelligence (AI), automation, and the Internet of Things (IoT) can help reduce costs and improve performance, but the high cost of implementation and cybersecurity risks are barriers.
Digital transformation in the oil and gas industry presents an opportunity to enhance operational efficiency, but implementing these technologies comes with challenges. Predictive analytics, driven by artificial intelligence and machine learning, can optimize production processes and enable predictive maintenance, which reduces downtime and improves asset longevity. However, with the increasing reliance on digital systems, cybersecurity risks also rise, making data protection a critical concern. Additionally, digital transformation requires a workforce with new skills, and companies must address these gaps through retraining and attracting tech-savvy talent to ensure successful implementation of these innovations.
KEY CONSIDERATIONS
Leveraging data analytics for predictive maintenance and production optimization.
Enhancing cybersecurity in increasingly digitized operations.
Addressing workforce skill gaps to support digital transformation.
Oil & gas companies that develop products such as undersea robots that support exploration and delivery face their own set of challenges. First, the use of document-based technology or siloed point software solutions fails to keep up with the increasingly complex hardware and software systems and subsystems that must perform flawlessly together. Second, reliance on manual tools that are not optimized for managing a complex development process often results in inefficient teamwork and late detection of defects.
As a result, companies find themselves:
Relying on inefficient meetings or email communications involving internal, partner and supplier teams to discuss, review and approve product requirements and tests
Missing opportunities to detect defects and other issues early in the development process when it is typically easier and less costly to ensure product quality and performance
Incurring contractual penalties or losing revenue due to delayed availability or delivery of products
https://www.jamasoftware.com/media/2024/11/2024-10_fueling-progress-challenges-oil-and-gas-ebook-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-26 03:00:262024-11-21 10:43:49Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects
In this blog, we recap a section of our Datasheet, “Jama Connect for Defense Systems: Integrate DoD MIL-STE-882E Risk Management with Systems Engineering” – Click HERE to read it in its entirety.
Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems
Align hardware and software systems safety using Jama Connect as your single, secure platform for requirements engineering, risk analysis, and test management.
Military departments and defense agencies must follow the MIL-STD-882E Standard Practice for System Safety to ensure safety throughout the entire lifecycle of military systems, including development, testing, production, use, and disposal.
A key challenge to compliance is the need to integrate risk management and collaboration into the systems engineering process systematically across system and fire protection safety and occupational and environmental health disciplines.
Relying on a manual, document-approach using Word and Excel to manage the MIL-STD-882E risk register is inefficient and error-prone. A more reliable and intelligent solution is Jama Connect for Defense Systems which provides a single, secure platform for requirements, risk, and test management throughout the development lifecycle. It enables alignment of software and hardware development teams to achieve speed and quality, auto-detection of safety and environmental hazards and risks for early identification and mitigation, and robust collaboration and reviews involving internal teams, supply chain partners and government agencies.
Align the hardware and software systems’ team safety activities. Manage risk management for hardware and software system safety in Jama Connect which provides a single source of truth that integrates with best-of-breed software tools chosen by various teams.
Identify hazards and risks for early mitigation. Teams benefit from a single system and integrated data model for architecture, hazard assessment, analysis, safety requirements, and tests.
Accelerate development by streamlining collaboration and reviews. Avoid development delays by making it easy for internal and external teams to participate in MIL-STD-882E activities with Jama Connect’s Review Center and collaboration intuitive capabilities.
Get the most out of your requirements management and traceability solution. Use the same Jama Connect solution for managing and documenting your product requirements AND your MIL-STD-882E activities to maximize your return on investment from Jama Connect.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.
https://www.jamasoftware.com/media/2024/11/2024-10_dod-mil-std-882e-risk-management-w-systems-engineering-datasheet-2-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-25 03:00:272024-11-20 11:51:07Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems
In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.
Key Systems Engineering Skills: Critical Thinking and Problem Framing
Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.
In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software®, discuss how critical thinking and decision-making skills are integral to systems engineering.
In this insightful session, you will learn:
Explore the vital role of critical thinking and decision-making in systems engineering.
Learn practical techniques for decision framing and closure.
Gain insight on how systems engineers should manage design decisions on a project.
See a simple model of how and when to engage with stakeholders in design decisions.
Below is an abbreviated transcript of our webinar.
Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.
In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.
So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.
Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.
Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.
So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”
Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.
So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.
So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.
Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”
They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.
Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.
https://www.jamasoftware.com/media/2024/03/Key-Systems-Engineering-Skills-Critical-Thinking-and-Problem-Framing.png5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2024-11-21 03:00:452024-11-18 10:07:27[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing
In this blog, we’ll recap a section of our recent Expert Perspectives video, “A Method to Asses Benefit-Risk More Objectively for Healthcare Applications” – Click HERE to watch it in it entirety.
Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications
Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.
In the complex world of healthcare, evaluating benefit-risk is crucial to successful product development and patient outcomes. Our expert perspectives video, “A Method to Assess Benefit-Risk More Objectively for Healthcare Applications,” offers actionable insights for healthcare innovators aiming to meet rigorous regulatory requirements while ensuring patient safety and efficacy.
In this episode of Expert Perspectives, Richard Matt breaks down a streamlined, objective method for benefit-risk analysis. He explores a structured frameworks and data-driven approach that help teams make balanced decisions, mitigate risks early, and stay compliant with regulatory standards, including FDA and ISO guidelines.
This patent-pending approach helps organizations navigate challenges, foster innovation, and ultimately bring safer, more effective healthcare solutions to market.
Below is a preview of our interview. Click HERE to watch it in its entirety.
Kenzie Jonsson: Welcome to our expert perspective series where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today, I’m excited to welcome Richard Matt. Formerly educated in mechanical, electrical, and software engineering and mathematics, Richard has more than thirty years of experience in product development and product remediation. Richard has worked with everyone from Honeywell to Pfizer and is now a renowned risk management consultant. Today, Richard will be speaking with us about his patent pending method to assess benefit-risk more objectively in health care. Without further ado, I’d like to welcome Richard Matt.
Richard Matt: Hello. My name is Richard Matt, and I’m delighted to be speaking with you about our general solution to the problem of assessing whether the benefit of a medical action will outweigh its risk. I’ll start my presentation by saying a few words about my background and how this background led to the benefit-risk method you’ll be seeing in the presentation.
To understand my background, it really helps to go back to the first job I got out of undergraduate school. I graduated with a degree in mechanical engineering and an emphasis in fluid flow. And my first job was in the aerospace industry at Arnold Engineering Development Center, at a wind tunnel that Baron von Braun designed. I worked there as a project manager, coordinating various departments with the needs of a client who brought models to be tested. These are pictures of the ADC’s transonic wind tunnel with its twenty-foot by forty-foot long test section that consumes over a quarter million horsepower when running flat out. Those dots in the walls are holes, and a slight suction would pull the out on the outside of the wall to suck the air’s boundary layer through the holes. So a flight vehicle appeared more closely to match its flight air characteristics in free air. It was amazing place to work.
We could talk about aerodynamic issues and thermodynamic issues like why nitrogen condenses out of the air at mach speeds above six or why every jet fighter in every country’s air force has a maximum speed of about mach three and a half. But to stay on the topic of benefit-risk, the reason or my intro to this, the reason I was brought this up was that I saw here firsthand the long looping iterations that came from different technical specialties, each approaching the same problem from the respective of their technical specialty. I found it very frustrating and the, following analogy very apt, after getting, so each of our technical specialties would look at the same problem, the elephant from their own view. And I found myself getting frustrated with my electrical and software engineering coworkers, that they didn’t understand what I was talking about, but I knew realized soon I didn’t understand what they were talking about either.
So I decided I wanted to become part of the solution to that problem by going back to graduate school and getting myself rounded out and my education so I could talk to these folks from their perspective also. So I went back to grad after mechanical and undergraduate, went back to graduate school in electrical and mathematics and picked up enough software. I started teaching, programming also in college. I developed there a solution for the robot arms in those wind tunnels to to control a robot arm for every possible one, two, or three rotational degree of freedom arm, and that was my graduate thesis. After I completed my thesis, I felt empowered to start, my work doing going wherever I wanted doing whatever I wanted to do and realized that if I wanted to do anything significant, it would take many years, and I decided to focus on teamwork. Does that sound pretty good?
Matt: My ability to work across technical boundaries enabled me to bring exceptional products to the market. For instance, I brought an Internet of Thing (IoT) device to the market during the nineteen nineties before Internet of Things was a thing. And I rapidly advanced while I was working as a VP of engineering at a boutique design firm in the Silicon Valley. These are a few of the clients that I had, through the work that I’ve done over the years.
And, the combination of the breadth of my formal training and my system perspective for solving problems has really helped me work across continue to work across boundaries, so that I’ve worked for companies to help them establish their pro product requirements, trace requirements, do V and V work. I’ve done a lot of post-market surveillance work. I established internal audit programs. I’ve been the lead auditee when my firm is audited. Done had significant success accelerating product development and has been on work on. So mixed in with all of these works, I special I started specializing into risk management as consulting focus versus something I just did normally during development.
And since the defense of a patent requires notice, I’ll mention that the material here is being pursued on the patent, and, would like to talk with anyone who finds this interesting to pursue after you’ve learned about it. So let me start my presentation on benefit risk analysis by talking about how important it is to all branches of medicine and the many problems we have implementing it. The solution I’m gonna come up with, I’ll just outline here briefly so you can follow as we’re going through the presentation. I’m gonna first establish a single and much more objective metric to measure benefit and risk than people traditionally use. I’ll be accumulating overall benefit and risk with sets of metric values from this first metric. And finally, we’ll show how to draw a conclusion from the overall benefits and risk measurements of which is bigger benefit or risk.
So in terms of importance, historically, benefit-risk has been with medicine for millennia. It’s a basic tenant to all of medicine. The first do no harm goes all the way back to the quarter of Hammurabi 2,000 BC, and it legally required physicians to think not just about how they can help patients with treatment or what harm they might cause to treatment and making sure that the balance of those two favor the patient is very much the benefit-risk balance that we look at today. The result we’re gonna talk about is gonna be used everywhere throughout medicine with devices, with drugs, with biologics, even with clinical trials.
So is that fundamental cross medicine? How it’s used currently?
If you are in one of the ways developing new products, benefit-risk determinations have to be used in clinical trials to show that they’re ethical to perform, that we’re not putting people in danger needlessly. Benefit-risk determinations are the final gate before a new product is released for use to patients. And I have a quote here from a paper put out by AstraZeneca saying the benefit-risk determination is the Apex deliverable of any r and d organization. There’s a lot of truth to that. It’s the final thing that’s being put together to justify a product’s release. And so it has a very important role here for FDA and has a very important role for pretty much the regulatory structure of every country, including the EU.
Matt: In terms of creating a quality system, every medical company is required to have one. Benefit-risk determinations are used to assess a company’s quality system. This is per the FDA notice about factors on benefit-risk analysis. When regulators are evaluating company’s quality system, they’ll use benefit-risk to determine if nothing should be done, if a product should be redesigned, if they should take legal actions against a company of a range of possibilities from replacing things in the field to stopping products from being shipped. It’s also a key in favorite target for product liability lawsuits, because of how subjective it is, and we’ll get to that in a moment. It can also be used for legal actions against officers. So benefit risk is a really foundational concept for getting products out and keeping products out and keeping companies running well. Just a bit of historical perspective of medical documentation and development. We have here, I cited four different provisions of the laws, regarding medical devices in the United States. This is a small sampling.
The point I’m trying to make here is that each of these summaries of the laws discuss continually evolving, continually growing, more rigorous standards for evidence, more detailed requests for information from the regulators to the instrumentation development companies to the product development companies. So first, medical products are heavily regulated. We have the trend of increasing analysis and rigor. Per ISO 142471, and this is an application standard that is highly respected in the medical device field. A decision as to whether risks are outweighed with benefits is essentially a matter of judgment by experienced and knowledgeable individuals.
And this is our current state of the art.
Not that everybody does it this way, but this is the most common method of performing benefit-risk analysis. And benefit-risk analysis by this method, has a lot of problems because it’s based on the judgment and it’s based on individuals, and both of those can change with different settings. That’s why it’s a favorite point of attack for product liability lawsuits.
This quote was true in 1976, when medical devices were put under FDA regulation, but significantly remains unchanged nearly fifty years laters. Benefit-risk determinations are an aberration and that unlike the rest of medicine, they have not improved over time. They’ve remained a judgment by a group of individuals. In, twenty eighteen, FDA was, approached by congress to set a goal for itself of increasing the clarity, transparency, and consistency of benefit risk assessments from the FDA.
This was in human drug review as the subject, and the issue was that various drug companies had gotten very frustrated with the FDA for disagreeing with their assessments of what benefit-risk should look like. And to repeat again, when you have a group of individuals making a judgment, that’s gonna lead to inconsistencies because both the group and their own individual judgment will vary from one situation to the next. I have another, quote here from the article from AstraZeneca. The field of formal and structured benefit-risk assessments is relatively new.
Matt: Over the last twenty years, there’s still a lack of consistent operating detail in terms of best practice by sponsors and health authorities. So this is an understatement, but a true statement. We have had a lot of increasing effort over the last few years because if people are dissatisfied with the state of benefit-risk assessments, they want to do better than this judgment approach. And so there have been a plethora of new methods developed. I’ve found one survey here that summarize fifty different methods just to give you an idea of how many attempts there are. And I went through those fifty methods.
The other thing that’s interesting to see is the FDA’s attempt to clarify benefit-risk assessments. I have here five guidance documents from the FTA, and I would put forth the proposition that anytime you need five temps five attempts to explain something, it means you didn’t understand the thing well in the first place or failing about a bit trying to get it done right. I think this is also held up by the drug companies, pressure on congress to get FDA to improve their clarity and consistency of benefit-risk assessments.
So here’s the, fifty methods that I found in one study of benefit-risk assessments. They have them grouped into, a framework, metrics, estimate techniques, and utility surveys. These are the fifty different methods, and I’ve gone through each one of them. And they all have fundamental problems. They, I’m going through them a bit slowly. Like, here’s one, from the FDA, another benefit risk assessment. Health-adjusted life years are one of the few that uses the same metric for benefit and risk. Number needed to treat is a very popular indication for a single characteristic, but you can’t integrate that across the many factors that needed to do benefit-risk assessment.
And so we’ve gone down the rest of these, methods. If I group these fifty methods by how they accumulate risk, I get a rather useful collection. Most of the methods do not consider all the risk-benefit factors for benefit-risk situation. They will pick on just one factor. And you can’t combine the factors with themselves or with others. It’s simply looking at one factor by itself. So it’s an extremely narrow view of benefit-risk for most of these. The few methods that do look at all the risk-benefit factors, most of them start with what I call the judgment method, where you’re forced to distill all the factors down to the most significant few, only four maybe four to seven methods, four to seven factors.
So either the methods consider only one type of, one factor at a time, or they force you to throw away most of the methods and consider maybe four or seven factors is the second method. The third method is they assign numbers to the factors, they’ll add the factors together, and they’ll divide the benefit sum by the risk sum. And if the division is bigger than one, they’ll say the benefit’s bigger than the risk. And if the division is less than one, they’ll say the risk is bigger than the benefit.
https://www.jamasoftware.com/media/2024/11/Richard-Matt-Benefit-Risk-Medical-Application-1.png496882Richard Matt/media/jama-logo-primary.svgRichard Matt2024-11-20 03:00:282024-11-18 09:50:07Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications
In this blog, we recap a section of our whitepaper, “Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls” – Click HERE to read it in its entirety.
Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls
Reduce the risks of product rework and recalls by using tools that enhance the efficiency and accuracy of requirements management and aid in compliance with UL 4600, the Standard for Safety for the Evaluation of Autonomous Products.
The shift to software defined vehicles (SDVs) marks a pivotal change in the automotive industry’s journey toward full autonomy. Initially, there was a rush toward developing fully autonomous vehicles, but the complexity of this task led the industry to adopt a more gradual, phased approach. This market transition has given rise to SDVs, but unlike traditional vehicles, which remained largely unchanged after purchase and are based on dated architecture topologies, vehicle OEM’s can now scale their software investments and simplify and optimize the vehicle architecture. This has benefits not only for the developer — resulting in a reduced total cost of ownership, potential acceleration of development, and improved safety and security — but also for the consumer in the form of increased choice, new business models, and post-sales updates and fixes.
Improving product and software development processes and the tools that support them can more effectively enhance safety and security standards while mitigating the risk of costly midcycle rework and after-sales recalls.
In 2023, there were over 300 recalls affecting more than 25 million vehicles, with costs potentially reaching millions of dollars per recall.
The automotive industry has advanced significantly from even a decade ago. Once-basic features, like touchscreen navigation, have evolved into sophisticated connectivity options, voice assistance, app ecosystems, and more. These changes bring several development challenges, including:
Managing increased software complexity
As vehicles become more software defined, managing multiple software components provided by many different vendors that perform entirely different functions increases complexity. For instance, an electronic control unit might operate the antilock braking system, while a cockpit domain controller is responsible for a very different task. In a software defined vehicle these distinct software systems must work seamlessly across the vehicle without issues, adding further complexity to an already challenging development cycle.
Ensuring functional safety and security compliance
With increased complexity, automotive companies face additional challenges in keeping up with safety and security standards and the associated regulatory compliance. The development community has relied on ISO 26262 for many years as the required functional safety standard. But, while it has historically served as an excellent baseline, the standard did not account for software defined vehicles, autonomous vehicles, or many of the new use cases.
Standards are evolving to keep up, and new ones, such as UL 4600, have been created that directly tie to autonomous vehicles. However, these standards continue to require companies to build requirements, test those requirements, and demonstrate that they have done everything possible to build a safe and secure product.
The process is complex with SDVs, especially when considering the hundreds of millions of lines of code involved. Companies must show that no faulty code exists and that they have not inadvertently introduced back doors that could create security issues or conditions that could violate a safety goal. As a result, there is a need to reconsider old processes and tools for requirements management to meet the current development environment and support mitigating potential risks.
Difficulty in meeting accelerated timelines
The pressure to deliver products and software faster is a significant challenge. Technology evolves rapidly, and no sooner have you developed a vehicle than consumer needs and opportunities emerge, leaving you to redesign to keep up with the market, differentiate, and stand out.
However, meeting accelerated timelines can conflict with maintaining quality and compliance, making it critical to strike the right balance. Adopting tools that allow for automation and faster processes can help keep up with these demands while aligning with safety requirements and standards. As more and more companies adopt an Agile development methodology, it’s increasingly important that the associated development tools do not stifle the benefits that Agile can offer. One great example is the concept of Traceable Agile™ that facilitates instantaneous, in-cycle insight into coverage for Agile development teams.
Managing the dramatic increase of third-party software
Advancements in automotive development have led original equipment manufacturers (OEMs) to source software from multiple vendors. Integrating this level of diverse software while avoiding safety and security issues can be challenging. Now, you not only have to integrate hardware from various suppliers but also manage a massive software bill of materials (BOM) from different vendors, ensuring that everything works seamlessly together.
You also need to ensure that you’re not introducing bugs due to incompatibilities between systems, which can cause unexpected glitches, security vulnerabilities and safety issues. These are very expensive, can potentially delay product launches, and create negative brand impact.
Often, hundreds or even thousands of software elements come together, with tens of millions of lines of code. Ensuring that all these elements work together while remaining safe and secure, and meeting consumer expectations for a modern vehicle, is critical.
Four Major Challenges with Software Defined Vehicles
1. Managing increased software complexity. The industry is shifting quickly due to the integration of software in vehicles, which presents challenges in effectively and efficiently developing and deploying SDV’s.
2. Ensuring functional safety and security compliance. Automotive companies face challenges meeting safety and security standards and regulatory compliance, particularly with complex software systems.
3. Difficulty meeting accelerated timelines. The pressure to deliver products faster in the SDV space is a key challenge.
4. Managing the dramatic increase of third-party software. OEMs are sourcing software from multiple vendors and integrating this level of diversity while avoiding safety and security issues is difficult.
Solid engineering practices involve deciding what to build, defining a set of requirements, building it, and then testing it. This development lifecycle process ensures that you’re solving for the correct problem and is centered around requirements management.
However, many organizations use Excel sheets or Word documents to house requirements. Initially, this approach might not seem problematic, but as products become more complex and requirements grow, the spreadsheet approach becomes unmanageable. Copying and pasting requirements across documents creates opportunities for errors, a lack of a single-source-of-truth and a lack of traceability introducing the risk of expensive product or software issues.
You can address this challenge by replacing legacy processes involving spreadsheets and other solutions with a more robust, automated tool specifically designed for requirements management. This change eliminates manual processes that open the door to errors, improves efficiency, and reduces the risk of missed requirements — resulting in potentially millions of dollars of savings.
How Ford Selected a Single Requirements Tool for SDV Architecture
In 2022, Ford selected Jama Connect as a single requirements tool. The company started to deploy the tool focused on the development of a future software defined vehicle architecture.
Before Adopting Jama Connect
Engineers often lacked formal training in writing requirements.
Unconstrained natural language often contained large specifications (non-atomic).
Poor requirements were the standard, and engineers had no automatic ways to receive feedback.
Suppliers received thousands of requirement specifications in PDF, but some didn’t apply.
Signing-off on products was a manual process, with engineers often having to chase down test results.
After Adopting Jama Connect
Requirements engineering is a discipline with training easily available and just-in-time.
Engineers receive immediate and automatic feedback on requirements quality.
Product-line engineering automatically defines what is applicable to a variant of a product.
Dashboards show real-time and transparent progression of product sign-off.
https://www.jamasoftware.com/media/2024/11/2024-11-19-stragegies-mitigating-software-defined-vehicle-risk-1.jpg512986Jama Software/media/jama-logo-primary.svgJama Software2024-11-19 03:00:032024-11-15 16:02:48Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls
In this blog, we recap our recent webinar, “Achieving ASPICE 4.0: Overcoming Key Challenges” – Click HERE to watch the entire thing.
Achieving ASPICE 4.0: Overcoming Key Challenges
The path to ASPICE 4.0 compliance can be complex. Gaining a deeper understanding of traceability requirements, process consistency, verification criteria, and special characteristics is essential to improving your development processes and achieving compliance.
How to implement robust traceability methods for ASPICE 4.0
Techniques to maintain consistency across processes
How to define and implement effective verification criteria
The significance of special characteristics in automotive software development
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Ronald Melster: Thank you for the warm introduction and thank you very much for inviting me to today’s webinar. I’m excited to be here with all of you to discuss the challenges and updates that we encounter in the latest version of the ASPICE standard. So let’s get started and explore what these changes mean to our industry and how we can best adapt to them. Why are we doing this webinar? The release of ASPICE 4.0 has brought new requirements and expectations and created some confusion.
In this session, we will discuss four key areas of change that are especially challenging and potentially misleading. This webinar is designed to clarify these updates and help you understand the implications. Here are the four changes I will talk about. First, we will look at the changes on how to connect elements across the V-model. Then we move on to consistency, as there is an increased emphasis on maintaining consistency across work products. I would share how this topic impacts your daily work. Then we discuss our favorite topic, the verification criteria. The base practice and the work product for the verification criteria have been removed from the standard. The question is if the need for a verification criteria is gone as well. And the last change I will talk about today are the special characteristics. This new concept was introduced with PAM for 0.0. I will explain why this is necessary and how it can be implemented.
Some of you may know me already, but for those of you who don’t yet, let me introduce myself briefly. I’m Ronald Melster or simply Ron in the automotive world. As one of Europe’s longest-serving ASPICE assessors, competent since 2005 and now principle, I’ve dedicated my career to guiding organizations through process improvements, always striving to balance structure with pragmatism. After my early work in software engineering and quality assurance at Fraunhofer, where I researched on knowledge management and 3D visualizations, I entered the automotive industry in the year 2000. Over the years, I found that meaningful assessments involve much more than simply rating. It’s about helping people to understand the why behind each process. Today, I coach companies and teams through their ASPICE improvement projects, working with companies like Bosch, Audi, and Porsche to help them reach the capability levels one, two, and even three. Together we are shaping more effective motivated teams that understand not just the how, but the purpose behind the ASPICE standard.
Melster: The first topic I will talk about is traceability. A very common misunderstanding is that a trace must be a direct link to click on, and then I end up at the target element. This was never the expectation and has been clarified with PAM 4.0 in the respective VDA guidelines. Before I run you through the possible traceability techniques, let’s discuss why traceability is essential for successful project management and product development, starting with the impact analysis of change requests. Traceability allows us to clearly track the origin and implications of each change request. By establishing traces, we can see where a change affects other components, documents, or requirements. This is particularly crucial for ensuring that safety and security requirements are met consistently. Next, we have root cause analysis of problems. With traceability, we can identify not only the immediate issue, but also trace it back to the process step where it was introduced.
This can help to prevent similar issues in future cycles by allowing us to adjust processes or documentation at the root cause level, instead of merely fixing surface-level symptoms. And traceability can help to show the completeness of work products. Traceability helps us to verify that all necessary parts of the system are complete and that each requirement has been successfully implemented. This is especially critical in safety and security cases, where missing traces could mean non-compliance or safety issues, or vulnerabilities.
Finally, traceability enables progress tracking. By using trace links, we have a clear and consistent overview of how far along each requirement is in the process. This enables project managers to track progress more accurately. In essence, traceability ties every piece of the project together, ensuring that we understand the why and how behind each element, and helping us maintain quality, safety, and security. Let’s have a look at the first traceability technique, which are naming conventions. The idea is to use the name of one artifact to identify another artifact. For example, the name of the unit, which is defined as part of the detail design, is used to identify the source code file or the function in the source code. Of course, the naming convention has to be described in a central document to make it available to everyone in the project.
Our next traceability technique are editorial references. This method uses the same ID as a text reference across documents that need to be connected. It’s a straightforward approach, often called traceability light, because it doesn’t require complex tools at the start, just the ability to update text in both documents. The question remains how to trace back. There are a few approaches that we can take. The first one is contextual searching. In the traceability strategy, we can specify how to search within the databases or text documents for these IDs, allowing to navigate across documents. Another method is to create a mapping table serving as a lookup tool that aligns IDs from one document to another. Finally, we can use tools like Rectify, that scan the text documents and provide statistics about the coverage of the traces.
Melster: Our third traceability technique is hyperlinking. This approach creates direct connections between tools, making it easier to trace items across different systems. With hyperlinking, each item has a direct link embedded in the document or tool, so rather than manually searching for information, you simply click the hyperlink and it brings you straight to the related item in another tool or document. Our fourth and last technique for establishing traceability are tool links. Many modern tools can create direct links or traces between different elements or requirements, streamlining the process of tracking dependencies and relationships across the project. Tool links often add semantic context to each trace, such as implements or is implemented by. This provides clarity on how the elements are related, making it easier to understand the purpose behind each link. One powerful feature these tools provide are suspect links. These are automated flags that notify us when a linked requirement or element is modified. This way we can quickly perform impact analysis and assess whether changes in one area affect other linked elements, helping us manage risks and ensure consistency across the project.
Another change that comes with PAM 4.0 are clusters of elements. This means that instead of establishing links from one single element to another single element, we can now create traceability links at a higher level. For example, we can trace groups of requirements that share common goals, we can trace two architectural elements within a particular subsystem, or we can trace software units associated with a specific functionality. This flexibility allows us to handle complex systems more efficiently, as we are not restricted to tracing every single element individually. However, this comes with more responsibility, as it is more important to remember that the level of traceability must still be appropriate for the product, and it is more complicated to provide the statistics for coverage, because we cannot just simply count items which are connected. And finally, the justification for consistency becomes much more important. For example, do the test cases which are linked to a cluster of requirements completely cover this cluster, or is there something missing?
Another important change I would like to highlight is that it’s now possible to trace from stakeholder requirements on SYS.1 directly to software requirements SW.1. There is no need to link via the system requirements to the system architecture to the software requirements anymore, if the stakeholder requirements are specific enough and have no impact on any other part of the system other than the software. This approach is often used in software-only projects, where the stakeholder requirements are already very specific. However, in system projects, the impact on the system must be considered in a comprehensive way. The same approach can be used for hardware requirements and mechanical requirements as well.
Another big change from PAM 3.1 to 4.0 is that there’s now a combined base practice for traceability and consistency. In ASPICE PAM versions 2.5 and earlier, we used to assess consistency and traceability together in one based practice. In PAM 3.1, they were split into two based practices for traceability and consistency, and VDA guidelines define the strong relationship between these two base practices, because these two concepts are inherently connected. To explain why, let’s consider this. Consistency depends on having effective traceability. Without solid traceability between work products, we are not able to guarantee that the elements align correctly throughout the development process. For example, if requirements are not traced to elements of the architecture or test cases, showing the evidence for consistency between these artifacts becomes nearly impossible. Therefore, checking for both consistency and traceability as a unified practice makes sense, as it ensures that all pieces are in sync and meet the intended quality standards.
Melster: Let’s have a closer look at an example for consistency, which base practice or base practices in SW.1. Software requirements analysis deal with consistency. Obviously, base practice five directly addresses consistency by requiring us to establish bi-directional traceability between software requirements and the system architecture, and software requirements and system requirements. This base practice ensures that each software requirement is directly aligned with the system architecture and linked back to the respective system requirements. The idea here is to maintain clear connections, ensuring that the requirements are accurately reflected across all levels of design. The second base practice, which deals with consistency is base practice number one, it’s a little bit hidden in node two. This node defines characteristics for requirements like verifiability, comprehensibility, freedom form implementation and surprise surprise, not contradicting other requirements, which is the synonym for consistency.
So we have two types of consistency in software requirements, external and internal. External consistency ensures alignment between software requirements, system requirements, and the elements of the system architecture. Each of these checks involves typically two different documents and it compares different artifacts, software requirements with system requirements, and software requirements with the elements of the system architecture. This is why I call this consistency, external consistency. And we have to fulfill BP-1, which can be done checking for internal consistency. For SW.1, that means software requirements are checked against other software requirements. This activity is essential for ensuring the integrity of our requirements. The primary goal of this verification is to ensure that the requirements do not contradict each other. There are many references and standards such as ISO IEEE 29148, ISO 26262-8, and the INCOSE Guide for Writing Requirements. They have one characteristic in common, that requirements shall not contradict each other.
This is one of my favorite topics. I have had discussions about this for years. Do we need an explicit verification criteria, yes or no? Now the base practice and the work product have been removed. What does this mean? This removal of the explicit verification criteria requirement in ASPICE PAM 4.0 marks a significant change, streamlining the base practices for evidence of verifiability. While previous versions of ASPICE emphasized having a separate verification criteria as a formal step, this requirement has been softened in PAM 4.0. However, demonstrating variability remains a crucial practice as we have seen. Projects must still make sure that there’s an evidence that each requirement is verifiable, though it’s no longer mandatory to document a distinct verification criteria for each requirement. This adjustment suggests that verification is evolving in focus. Instead of a string and isolated criteria, there are other ways to ensure the verifiability, performing review by the test team for example.
Melster: This ensures that requirements can be tested or writing simpler requirements if this is possible, of course, but for straightforward requirements, there’s no need to have an explicit verification criteria. However, for more complex system requirements, writing a verification criteria might still be recommended, so writing a verification criteria has become a best practice instead of a base practice. The decision and the responsibility for justifying this decision lies with the development projects now. And the last topic I would like to talk about are special characteristics. What are they and where do they come from? These special characteristics are often identified through structured risk assessments, such as FMEA, failure mode and effects analysis, which is commonly used to prioritize potential failure risks. Or HARA, hazard analysis and risk assessment, which helps identify safety critical elements. And of course TARA, threat analysis and risk assessment, which focuses on cyber security and vulnerabilities.
In terms of application standards, like IATF 16949, specify that these special characteristics should be integrated into the system architecture, as well into the hardware design. This ensures that all key attributes affecting system safety and compliance are identified from the start. An essential part of managing special characteristics is ensuring that they are verifiable. According to VDA volume one, special characteristics must be documented in a way, so that they can be reviewed and validated. This verifiability ensures that all compliance and safety requirements are traceable and systematically implemented. This concludes our little journey into the changes and challenges with PAM 4.0. If you want to learn about RSPICE, consider joining the Melster Academy or book a personal meeting with me to find out how you can elevate your ASPICE expertise. I am looking forward to support your journey. Thank you very much for your attention. I will now hand it back to Sathiya and I will be happy to answer any questions you may have at the end of the webinar.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.
