Accelerated Automotive Product Development using DevOps

The automotive industry, which is more than 100 years old, has been going through significant disruption in multiple areas including technological advancements, accelerated product development cycles, green mobility initiatives, evolution of Internet of Vehicles (IoV), Edge Computing, Drive-by-Wire (XBW), and Over the Air (OTA) Software updates. As many of the vehicles have been increasingly adopting more and more advanced electronics and related Hardware and Software, in contrast to the earlier dominant mechanical systems, new features with increased complexity of development and launch are finding their place in the vehicles. Of late, the differentiators among different brands and vehicle variants on performance and features are noticeably defined by Software. Though software plays a very important role in enhancing capabilities in vehicles such as latest innovations in semi-autonomous driving, Advanced Driver Assistance Systems (ADAS) etc., it is also creating development challenges for automotive players with enormous costs of integration and upgradation of features, faster turn-around time, and bullet proof reliability and performance expected from customers, besides data privacy and cybersecurity. In the recent past, automotive OEMs had to incur expensive recalls to fix SW vulnerabilities due to hacking or to address issues such as non-deployment of airbags during crash situations. 

As can be seen from Figure 1 (Ref [1]), the software complexity has been increasing by many multiples (top solid curve) while development productivity and innovation in auto industry will barely increase by 2030 (bottom solid curve) with productivity of technology leaders, though outpacing the automotive players, still cannot catch up (middle dotted curve), indicating widening gap between SW complexity and productivity. Additionally, with rapidly evolving technology and the market dynamics demanding faster turnaround time, the non-availability of specific skilled workforce and/or difficulties in training or redeployment of resources in Automotive OEMs and Tier 1,2 suppliers will further compound the problem of addressing the widening gap between SW complexity and productivity. 

Frequently, the development of automotive SW modules occurs in silos with little cross-pollination among teams within the OEMs and with other modules purchased from or co-developed with strategic suppliers, essentially stitching together discrete SW modules, which the OEMs try to convert into a proprietary SW platform. As new features on a next generation vehicle may call for new SW development or enhancement of existing SW on multiple domains comprising hundreds of functional components in the vehicle and on cloud (Figure 2, Ref [1]), OEMs typically interact with multiple suppliers and SW vendors to build the required capabilities, ending up with a piecemeal approach (operating systems, SW architectures, development languages etc.) as no single SW platform can meet all the needs. Though automotive OEMs significantly reduced the SW development costs and timelines by tapping into other industries such as a) Aerospace and Manufacturing automation for ADAS software, b) smartphone industry for infotainment and automotive variants of mobile operating systems, and c) real-time operating systems (RTOS) from embedded software vendors and semiconductor suppliers, development of automotive features increasingly relies on seamless integration among multiple vehicle subsystems with urgent need for end-to-end platform to connect everything together. The accelerated SW development, inter-connectivity of feature development on multiple vehicle subsystems, daunting task of SW interface control and integration, and the urgent need for collaborative effort among OEMs, Tier 1,2 suppliers, and SW vendors for an end-to-end SW platform development, is a clarion call to reorganize in terms of the software development process called DevOps (Figure 3, Ref [2]). 

II. The Role of DevOps in Accelerating SW Deployment

Development and Operations, DevOps for short, includes collaboration, continuous integration, continuous deployment, and continuous feedback, with the ultimate goal to increase the cycle speed between feedback from end-user to an updated software. The objective of DevOps is to accelerate the SW development process and reduce the time to market by breaking down “silos” within an organization and utilizing cross-functional teams (CFT) more effectively. The DevOps practice includes a full-fledged product development cycle, applicable in multiple industries including Automotive. 

As can be seen from Figure 3, Ref [2], DevOps pipeline consists of 8 phases. 

1. In the Plan stage, requirements from the customers are captured and feedback/lessons learned from different stakeholders are incorporated to build a product roadmap even before the developers start writing code. 
2. During Coding phase, the SW development team usually has the standard toolkit and set of plugins to help write consistent code-styling avoiding common security flaws, aiding collaboration by providing consistency, and preventing failed builds/SW tests down the pipeline. 
3. After the coding is done, in the Build phase, the SW developer typically submits a pull request to merge their new code with the shared code repository, which would be reviewed manually by another developer and the pull-request approved if there are no issues. The pull request triggers an automated process which builds the codebase and runs a series of end-to-end, integration and unit tests to identify any regressions. If any of the tests fail or if the build fails, the pull-request fails, and the developer is notified to resolve the issue. By continuously checking code changes into a shared repository and running builds and tests, any integration issues that arise are minimized and SW bugs are identified early in the development lifecycle during Build phase. 
4. In the Test phase, after Build succeeds, the SW is automatically deployed to a staging environment such as an existing hosting service or a new environment (Infrastructure-as-Code) provisioned in the SW deployment process for deeper, out-of-band testing comprising a series of manual and automated tests. While the manual testing might be similar to how an end user might test (User Acceptance Test), the Automated tests might run security scanning against the application, check for changes to the infrastructure and compliance with hardware, run the application for load testing, and essentially establish the testbed without impacting the SW developers upstream or the production environment downstream. 
5. The Release phase is an important stage in DevOps pipeline where the Build is considered ready for deployment into the production environment after the code has passed a series of manual and automated tests. Developers can use feature flags to turn off new features so they can’t be seen by the customers until they are ready for action. As per DevOps methodology, Sr. Executives in an organization may manually decide either the minimum criteria for a milestone to be reached or authorize SW release schedule into the production environment. 
6. In the Deploy stage, a build is ready for release into production for which several tools and processes can be used to automate the release process and make them reliable with no outage window by using the same Infrastructure-as-Code (IAC) that built the test environment to be configured to build the production environment. The new environment sits alongside the existing production environment and when it is ready, the hosting service points all new requests to the new environment. In case of any issues with the new environment, the hosting service can point requests back to the old environment while the new environment is fixed. 
7. After a new release is live, the Operate phase of DevOps kicks in with operations team taking over. Depending on the configuration of the hosting service, the environment automatically scales with load to handle highs and lows in user activity. The feedback from the customers that test and use the application is collected for further improvement. 
8. The final phase of DevOps cycle is to monitor the environment, collate the feedback from the customers and provide a dashboard of data analytics on product performance, customer feedback, specific drawbacks, if any based on real world usage. The information is provided to the development team for continuous evolution of the product through its lifecycle. 

In Figure 3 (Ref [2]), 4 main aspects of DevOps are shown, viz., Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment (CD), and Continuous Feedback (CF), essentially emphasizing the core concept of “Continuity” of DevOps. 

1. In the Continuous Integration (CI) mode of DevOps, developers can integrate code modifications into the main branch of the code with automatic testing of the integrated code but ensuring the safety of the code in the main body. Owing to multiple developers and often in different locations and time zones, a shared code repository is used to coordinate the SW development, minimize the impact on someone else’s code & performance, and merge the changes made by multiple coders on the same piece of code. Continuous integration aligns with the Code and Build phases of the DevOps pipeline and regularly merges a developer’s code into the shared code repository and conducts automated testing to ensure that no errors/deviations have been introduced. The emphasis in CI mode is to merge smaller changes of developer’s code into the main code successfully, improve overall productivity and avoid bigger surprises later in the development cycle. 
2. The Continuous Delivery (CD) mode of DevOps cycle is a natural extension of CI mode wherein code updates are automatically generated, validated, and scheduled to be released.  After CI mode, CD mode extends by deploying all code improvements to a testing environment and a production environment after the development process. Continuous Delivery aligns with the Test and Release phases of the pipeline and allows organizations to manually trigger the release of new builds as regularly as they choose. 
3. The Continuous Deployment (CD) mode is an advanced version of Continuous Delivery mode but without the manual step of approving new releases into production. Here, each build which passes all the checks and balances of the pipeline are automatically deployed into production. 
4. The Continuous Feedback (CF) mode of DevOps helps get feedback from the customers based on their real-world usage, specific inputs from different stakeholders, and data analytics of usage for continuous improvement and better design for next set of changes. The CF mode closes the loop, feeding back data and analytics from the Operate and Monitor phases back into the Plan phase to start over the development cycle. 

Additional aspects of DevOps that need mention are the following:

1. Microservices Architecture

As the name indicates, in this architecture used in DevOps, the software code is developed as a continuum of small services and integrated together.  Each service manages its own process and interacts with other services with the help of a simplified structure/asset light framework or suitable programming languages. This helps improve productivity, reduce complexity, and quicken resolution of issues. 

2. Version Control Systems

As the name indicates, this standard approach in DevOps handles codes in versions and allows SW developers to work together collaboratively, effectively share the coding tasks among product team members, and optionally save the entire code for fast recovery, as required.

3. Infrastructure-as-Code (IAC)

The infrastructure-as-code (IAC) facilitates continuous integration/continuous delivery (CI/CD) aspects of DevOps and is an approach to the management and organization of infrastructure by using scripts to automatically set up a specific configuration of the environment for implementation (networks, virtual machines, etc.), regardless of its initial state. 

4. Monitoring & Logging

This stage of DevOps is used to monitor and check how the performance of applications and systems affects the experience of end-users of products and applications. Also, the user logs are tracked, and data metrics are captured for further analytics. This phase of DevOps is also used to carry out data protection and cybersecurity and ensure data privacy besides understanding how data logs generated by code changes or SW updates or infrastructure changes affect customer response, for further improvement in the product for the next cycle of SW release. 

III. Why DevOps in Automotive Product Development? 

Over the past few decades of 100+ years of automotive industry existence, software has become an indispensable part of automotive product development. The auto industry in 2020s is probably going through a similar journey as the IT industry of 1990s and 2000s. Most of the new features or changes in upgradation of existing vehicles or in the launch of new vehicles are “Software centric”. There is continued pressure for reduced product delivery timelines. Though the Hardware costs might be going down, the corresponding complexity on SW is increasing with higher levels of reliability demanded by regulators and customers for semi-autonomous and autonomous vehicle features. This is also a great opportunity for auto industry to provide disruption in mobility never seen before.

Many of the vehicles these days boast of few hundred million lines of software code that has become a key differentiator and influencer on vehicle branding, marketing, and buying decisions by the customers. Akin to the many mechanical or mechatronic components in conventional Internal Combustion Engine (ICE) vehicles or the modern Electric vehicles (EVs), modern Software Development Lifecycle (SDLC) also consists of many interconnected systems with inputs and outputs. The SDLC includes design, development, and testing at component/system/lab/pilot production level before release for production. A common misconception in the auto industry is, software can be easily reproduced on multiple vehicles and will last forever unlike the mechanical parts that have wear and tear and need to be repaired or replaced. Also, SDLC is usually underestimated by many managers and Sr. Executives in the auto industry with the misconception that SW is easier to create, deliver, and manage. As modern vehicles have multitude of Electronic Control Units (ECUs) to manage different functions, logics, and performance, that are provided by OEMs themselves or Tier 1 or Tier 2 suppliers or SW vendors, the automotive industry has reached a stage where updating, upgrading, improving, and repairing units involves developing and deploying SW updates either physically or remotely and not necessarily fixing hardware issues manually in dealer locations or service centres. 

A) Evolution of Automotive SW Development 

i) Waterfall & Agile Methodology of Project Management

Automotive industry has been traditionally using the waterfall methodology for project execution with deliveries passing through series of quality gates with mechanisms having very little feedback loop (Figure 4, Ref [3]). Many project managers in auto OEMs using waterfall methodology realized that oftentimes there are many unresolved SW issues that

need to be resolved though they are just few months away from production. This obviously led to lot of frustration, finger pointing, and sometimes distractions away from the issues that need to be resolved. Automotive companies have since changed to Agile methodology, started having regular stand-up meetings, improved the gap in system testing, caught up on lost time and delivered the project on time or through minimum delays. The system testing approach in many cases is quite sketchy and the customer requirements also go through multiple changes. To avoid project delays, bring better clarity on system testing, and address the changing customer requirements, many companies are adopting A-SPICE methodology and achieving Level 2 or higher-level certification and delivering projects on time and with quality. However, in a good number of projects, the man hours are underestimated and for delivering the project on time, companies must spend many more man hours than originally estimated, leading to significant erosion in revenues and profits. A close study of tool chain and reviews of processes and artifacts may point out to the excess amount of man hours that each project associate may be putting into delivering the project on time and with quality to cover up the inefficiencies in the system and improve the processes. 

The schematic of Waterfall Automotive SW development in Figure 4 (Ref [3]) shows handover of deliveries across tiers, with customer requirements on the left side and delivery to the customer and feedback on the right side of the V-product development cycle. As we move down from the left side of V-cycle from customer requirements to OEM specs down to Tier 1 Statement of Requirements (SOR) and Tier 2 Scope of Work (SOW), with output coming back to Tier 1 from Tier 2 as code, which in turn comes back to OEM as SW, test data and compliance reports, we realize that it is a lengthy process. The waterfall approach (V-cycle) usually takes few years to deliver a product and few months to fix any issues. 

Agile SW development, on the other hand, is flexible, iterative, and involves rolling wave planning and less documentation, but focuses instead on increased demonstration (Figure 4, Ref [3]). The cons of Agile methodology include questions such as 1) do we have enough documentation to cover the regulations, 2) do we have enough resources, and 3) how do we manage the risks if we don’t think of them ahead of time? 

ii) SW Testing

When it comes to testing, a lot of automotive testing is still manual, with someone writing the test cases and someone else doing the testing against specific inputs, monitoring the outputs, and generating the Pass/Fail test report. System testing happens after internal release – someone has to release the SW, someone else has to flash it, and a system engineer/validation team has to test it and generate the test report. Usually, the test cases are project specific and are not necessarily flexible to be carried over to other projects. The focus is mostly on testing, to check if we have the right inputs, right test setup, right diagnostic tools, and right interpretation of the output and not on test case design. The feedback is still relatively slow, taking anywhere from couple of weeks to few months. After all this, if the test results are not favourable, there is always finger pointing if the right SW version was used with the right HW in the test environment. Also, SW release engineer may say, specific test cases cannot be tested with this version of the SW and hence questions the test output and the report. 

iii) Test Setup – Roles & Responsibilities?

Another important question that needs to be answered in Automotive SW Development is “Test Setup” – who owns the Grey Box, White Box, and Black Box testing?? Usually, there is no clear demarcation of SW team and System team roles and responsibilities. Also, this may span across multiple Tier 1 and Tier 2 suppliers, increasing the complexity further. Additionally, there is proliferation and duplication of test setups at OEM, Tier 1, and Tier 2 suppliers as each team wants to independently cross-verify the HW/SW combination and convince themselves. There is a large scope for improvement where there could be a combined strategy to distribute the scope of work and better utilization of test setups at OEM, Tier 1, and Tier 2 suppliers.

iv) Tools for SW Testing  

Another important topic in Automotive SW development is “Tools” and “Tool Myths” – On many occasions, it is falsely assumed that all the tools are created equal, are independent of process, and are interchangeable. The myth is that tools are considered the most significant cost item and the least contributing factor. As such, tools are the easiest to go in project budget cuts but as team members remain the same, there is always lost productivity due to some team members waiting for the availability of the tools. 

v) End Result

Net result of project management strategy (waterfall, agile), SW tools, SW Testing, and Test Setup is – lengthy product delivery and defect resolution timeline, nightmares for product teams in tracking, determining root cause, and providing feedback. It is often observed that there are certain areas of SW with over-testing as those areas have tools that are cheap and familiar — results in wastage of effort through duplication and proliferation. There are other critical areas where there are “gaps in SW testing” and these areas do not get the right attention due to multiple reasons such as 1) SW tools to test these critical areas are probably expensive with limited availability and long waiting period, 2) limited time/under pressure to test the SW to meet project deadlines, 3) potentially reducing the number/frequency of test cases (taking short cuts), resulting in poorly tested and released SW. 

Who pays the price? – 1) The end user or customer, who invests in the automobile. 2) OEMs themselves when there is a need for recalls to fix issues in the field – expensive affair. 

B) Need for DevOps in Automotive SW Development

As software plays a critical role in overall vehicle architecture, erroneous code or SW bugs can affect vehicle performance and safety, with many OEMs spending millions of dollars in the recent past on vehicle recalls across the globe. Recent technological enhancements on Development and Operations (DevOps) in the IT industry have opened the doors to the auto industry to quickly create reliable SW that meets and exceeds customers’ expectations through automated and continuous integration (CI), continuous delivery (CD), continuous deployment (CD), and continuous feedback (CF) modes, as shown in Figure 3 (Ref [2]). DevOps, with its continuous & collaborative approach, explores new collaborative mechanisms among design engineers, SW developers, code testers, IT operations, and quality assurance teams, resulting in increased trust, quicker feedback/change/check cycle, reliable and accelerated releases, and faster production deployment (Ref [4]). It eliminates older, slower, and siloed approaches to creating and deploying software. As the auto industry faces multiple challenges in terms of SW development, testing, and deployment,

while simultaneously adhering to strict safety and regulations in the local markets where they operate, the methodology of DevOps benefits auto OEMs and suppliers with faster time-to-market, continuous product quality improvement, increased productivity, higher reliability, happier customers, lower development costs, and faster experimentation of SW changes/new feature additions (Figure 5, Ref [5]). 

C) Challenges for Adoption of DevOps in Automotive SW Development

Though DevOps have been around for over a decade with early adoption in the IT industry, there are multiple challenges for adoption in the auto industry. 

1. The automotive product development has been using waterfall approach for many decades (Figure 4, Ref [3]), which calls for detailed planning at the beginning of the project. The waterfall approach is very documentation centric and has very fixed delivery timelines. The V-product development cycle is a lengthy process and usually takes few years to deliver a product. Software quality systems like A-Spice attempt to merge this approach with DevOps by setting up DMAIC (Define, Measure, Analyze, Improve, Control) processes. However, DevOps paired with Agile is found successful for automotive because this combination approaches software as an ever-changing realm and deals well with dynamically changing extraneous factors such as user expectations, environments, and security challenges. Though the Agile + DevOps combination works well for Software as a Service (SaaS), it has limitations while dealing with auto industry that is traditionally used to rigorous planning, Just in Time (JIT) inventory control, Flexible Manufacturing Systems (FMS), and multiple vehicle variants/trim levels. It might be easier to build Software in IT industry in iterations but the same extended to components, sub-systems, and systems in vehicle build is a tall order (Ref [4]).
2. Another important challenge in the adoption of DevOps in the automotive sector is deeply embedded in the automotive software stack. As can be seen from Figure 6 (Ref [4]), modern vehicles are equipped with dozens of Electronic Control Units (ECUs) with accompanying software for performance, navigation and infotainment, enhanced user experience, and safety, to name a few. Embedded software inherently has multiple limitations such as 

a) low computing and memory — Embedded software must work with a low footprint, leaving no room for orchestrators or extras like hypervisors, loaders, or maintenance-related code. 

b) diverse and disconnected tools to handle different ECUs from multiple suppliers — Despite the efforts by few Automotive players to standardize the ECUs and minimize their number in modern cars, the discrete suppliers of these ECUs are reluctant to lose their competitive edge in embedded SW control systems as they have significant sunk-in development costs and can provide advanced functionality with marginal cost increase and minimum change in Bill of Materials (BOM), which is what the OEMs demand. 

c) real-time response requirements — Real-time embedded software systems must ensure that response times are predictable and aren’t dependent on the system condition or conflicting turn of events. To design and verify such systems, very specific software stacks and tools are created with no anticipation of process automation. Even now, over 70% of SW deployments in the auto industry are done manually with little automation, thus leaving little or no room for DevOps automation testing unless the SW stack is changed completely.  

d) connectivity issues that are required for Over the Air (OTA) SW updates – auto OEMs have been slowly but surely utilizing V2X architecture and OTA updates but with the much prevalent 4G networks. With the advent of 5G networks and ultra-low latency, DevOps are expected to increase the efficiency of SW delivery cycle through CI/CD loops (Figure 7, Ref [4]). 

3. DevOps for embedded automotive SW faces unique challenges due to the complex testing matrix and deployment processes and the strict safety, regulations, and compliance rules associated with the auto industry. DevOps and CI/CD automation enables automotive manufacturers to accelerate their releases while ensuring security and mitigating the risk of failed/recalled software releases (Ref [6]).

D) Key Success Factors for DevOps in Automotive SW Development

The Key Success Factors (KSF) for DevOps in Automotive SW development include (Ref [5])

1. 360 Degree Lean Testing — Desktop benches, sub-system benches, system benches, and vehicle testing, so there is a scalability and increased complexity as we move from Tier 2 to Tier 1 to OEM with cost advantage at Tier 2, with simpler test setup.
2. Different Testing Contexts — MIL/SIL/HIL/System in Loop/Real World – we need to diversify to use different testing contexts, and if required use even cars in loop. Ideally, we should have progressively complex test setups as we go from Tier 2 🡪 Tier 1 🡪 OEM.
3. For successful CI/CD across OEMs and all Tiers, SW tools and test cases will be shared seamlessly over secured network. DevOps will also allow to cross pollinate the test cases so some of the Tier 1 test cases might run in the System context and some of the System test cases can influence Tier 1 testing. 
4. Strong processes — With A-SPICE as the starting point, which helps us with Project Management, Change Management, Risk Management, Problem Resolution Management, Product Release, and Measurement & Quality Management, it is imperative to build a scalable and agile concept which combines Waterfall project management and Agile methodologies. This will help the teams to plan well ahead of time (at a high level), and also keep it iterative and flexible (at deeper level). This gives rise to a) Scalable Agile (SAF) SW development that combines the best of waterfall + Agile methodologies and b) Scrum of Scrum where OEM, Tier 1 and Tier 2 are combined in Scrum teams and product owners can coordinate SW development using Concurrent Engineering, so no one has to wait for the next one to finalize the specs, a code, or a test case. 

5. Task Monitoring — build Integrated Ticketing pipelines with the right access and privileges to monitor the workflow, and check who is doing what and who is at what stage of development.
6. Change of work culture to be more collaborative — In addition to promoting a culture that supports more rapid development, DevOps also makes it possible to achieve more frequent application deployments. DevOps uses automation and reusable techniques to focus more on the strategic elements of the process rather than on routine tasks. The success of DevOps requires an organizational culture shift and is often cited as the most substantial challenge for its adoption.
7. Quality Assurance Board — provides dynamic, informative, and integrated feedback on where the roadblocks are. The KPIs of the dashboard include a) SW quality indicators, b) critical failures, and c) delays and dependencies (Figure 8, Ref [5]). 

Conclusion 

Software has been an important differentiator in branding and customer perception for automotive industry. Many auto OEMs have experienced significant recalls and associated expenses and revenue losses due to software glitches over the past few years, which is getting more complex due to addition of new features and compliance with new regulations.  Customers have been demanding and expecting new features and automatic updates in vehicles, but with quality and safety assurance, based on similar experience in the IT and mobile industry. The philosophy of DevOps, with continuous integration and continuous delivery, is the need of the hour, with regular/automatic liquid software over the air (OTA) updates, leveraging 5G networks and advances in cloud computing. Implementing DevOps and cloud in the automotive industry is quite a complex task that requires a lot of time and restructuring of internal processes. The challenges facing DevOps adoption in the auto industry need to be addressed by OEMs, Tier suppliers and SW & tool vendors by formalizing definitions and processes and coming up with standardization of ECUs and electronic components. With continuous updates, advances in cybersecurity, and ultra-low latency from 5G networks, the OEMs will have an opportunity for fixing bugs remotely with little or no recalls, provide enhanced user experience to the customers, and realize the transition to fully autonomous vehicles sooner than later. 

Future Work 

For successful DevOps adoption in the auto industry, future research should focus on a) wireless OTA software updates and bug fixes, b) ways to inherit best practices from open source such as standardization of APIs and open-source platform and tools, c) dynamic system scaling through automotive-grade virtualization of ECUs and infotainment stack, rapid development of field-programmable gate arrays (FPGAs) and Systems-on-Chip (SOC) and application-specific integrated circuits (ASICs), and automation of SW testing of in-vehicle embedded systems, d) speed up development of standards for DevOps in terms of definitions, processes, and tools, and e) exploit 5G networks and advances in cloud computing for faster, safer, and reliable SW updates (Ref [4], [6]). 

References

1. Fletcher, R. et. al, “The case for an end-to-end automotive-software platform,” McKinsey & Company, January 16, 2020, 

https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-case-for-an-end-to-end-automotive-software-platform

2. Pennington, J, “The eight phases of a DevOps pipeline,” https://medium.com/taptuit/the-eight-phases-of-a-devops-pipeline-fda53ec9bba

3. Juric, A., “Lean DevOps for Automotive OEMs,” M.S. Thesis 2021:63, Chalmers University of Technology, Goteborg, Sweden, 2021

https://odr.chalmers.se/bitstream/20.500.12380/304521/1/2021-63%20Antonio%20Juric.pdf

4. Starepravo, I., “DevOps – A Holy Grail for Automotive or a Budget Buster?” 

https://medium.com/hackernoon/devops-a-holy-grail-for-automotive-or-a-budget-buster-e45c801cfcc7

5. Akhtar, F., “Combining A-SPICE, Agile, and DevOps Development – Challenges & Opportunities,” VECTOR Software Testing Symposium, 2021, https://www.youtube.com/watch?v=hBLRmBDhpYg

6. Belagatti, P., The scene of DevOps in the Automotive Industry, July 2020, 

https://dzone.com/articles/the-scene-of-devops-in-the-automotive-industry

Author:

Dr. Arunkumar M. Sampath works as a Principal Consultant in Tata Consultancy Services (TCS) in Chennai. His interests include Hybrid and Electric Vehicles, Hydrogen & Fuel Cells, Connected and Autonomous Vehicles, Cybersecurity, Functional Safety, Advanced Air Mobility (AAM), AI, ML, Agile SW Development & DevOps, Edge Computing, and Data Analytics.