This is why the editors at Engineering.com designed our Digital Transformation Week event—to help engineers unpack all the choices in front of them, and to help them do it at the speed and scale required to compete.

Join us for this series of lunch hour webinars to gain insights and ideas from people who have seen some best-in-class digital transformations take shape.

Registrations are open and spots are filling up fast. Here’s what we have planned for the week:

September 22: Building the Digital Thread Across the Product Lifecycle

12:00 PM Eastern Daylight Time

This webinar is the opening session for our inaugural Digital Transformation Week. We will address the real challenges of implementing digital transformation at any scale, focusing on when, why and how to leverage manufacturing data. We will discuss freeing data from its silos and using your bill of materials as a single source of truth. Finally, we will help you understand how data can fill in the gaps between design and manufacturing to create true end-to-end digital mastery.

September 23: Demystifying Digital Transformation: Scalable strategies for Small & Mid-Sized Manufacturers

12:00 PM Eastern Daylight Time

Whether your organization is just beginning its digital journey or seeking to expand successful initiatives across multiple departments, understanding the unique challenges and opportunities faced by smaller enterprises is crucial. Tailored strategies, realistic resource planning, and clear objectives empower SMBs to move beyond theory and pilot phases, transforming digital ambitions into scalable reality. By examining proven frameworks and real-world case studies, this session will demystify the process and equip you with actionable insights designed for organizations of every size and level of digital maturity.

September 24, 2025: Scaling AI in Engineering: A Practical Blueprint for Companies of Every Size

12:00 PM Eastern Daylight Time

You can’t talk about digital transformation without covering artificial intelligence. Across industries, engineering leaders are experimenting with AI pilots — but many remain uncertain about how to move from experiments to production-scale adoption. The challenge is not primarily about what algorithms or tools to select but about creating the right blueprint: where to start, how to integrate with existing workflows, and how to scale in a way that engineers trust and the business can see immediate value. We will explore how companies are combining foundation models, predictive physics AI, agentic workflow automation, and open infrastructure into a stepped roadmap that works whether you are a small team seeking efficiency gains or a global enterprise aiming to digitally transform at scale.

September 25: How to Manage Expectations for Digital Transformation

12:00 PM Eastern Daylight Time

The digital transformation trend is going strong and manufacturers of all sizes are exploring what could be potentially game-changing investments for their companies. With so much promise and so much hype, it’s hard to know what is truly possible. Special guest Brian Zakrajsek, Smart Manufacturing Leader at Deloitte Consulting LLP, will discuss what digital transformation really is and what it looks like on the ground floor of a manufacturer trying to find its way. He will chat about some common unrealistic expectations, what the realistic expectation might be for each, and how to get there.

The post Register for Digital Transformation Week 2025 appeared first on Engineering.com.

In 1908, the Ford Motor Company introduce the Model T, the first truly affordable, mass-produced automobile in history. Ford’s assembly line techniques were so advanced for the time that the Ford production system and management strategy was called “Fordism” and was regarded as the future of all manufacturing.

Today, the Ford Motor Company is attempting to do it again, with a major project to rework the massive Louisville Assembly complex into a paragon of modern automotive manufacturing, replacing the traditional linear assembly lines with a root-and-branch structure that will involve discrete assembly of major modules, based on large-format aluminum die castings. The goal is to create a $30,000 midsize electric pickup, a wide-open market that is currently unexploited.

The automotive industry is watching, and if successful, the project could give Ford a significant advantage in the transition to electric vehicles.

***
Access all episodes of End of the Line on Engineering TV along with all of our other series.

The post The Model T Ford revolutionized the automotive industry. Ford is trying to do it again. appeared first on Engineering.com.

Morgan Maia, senior manager for technical partnerships at Oracle Red Bull Racing, Alba Colón, director of technical partnerships at Hendrick Motorsports, and John Church, president of JDC-Miller MotorSports sat down with moderator (and former professional racing driver and host of the YouTube motorsport engineering channel Driver61) Scott Mansell to share their unique perspectives on three different forms of motorsport: Formula One, NASCAR, and IMSA.

What follows is an edited and abridged version of their conversation.

Scott Mansell: You each represent very different forms of motorsport with very different challenges. Can you take a minute to explain your discipline?

Morgan Maia: Sure. In Formula One, the challenge is massive. We have 24 races a year, traveling around the world—from China and Japan to the U.S. and Europe. It’s difficult to always have the car in one piece because we have to trust that everything works straight off the truck without all the tools at hand.

Another challenge is the cost cap. We cannot spend more than $150 million per year. While that sounds like a lot, it goes quickly once you account for employees, parts, travel, and logistics. The challenge is to compete within those limits while ensuring both drivers perform at their best across 24 races.

Alba Colón: Can I have your budget? (laughs) NASCAR is a bit different. Imagine 40 cars running 38 weekends a year. Just last week, for the first time, we raced outside the U.S. in Mexico. We don’t only race on ovals, like in Las Vegas, we also compete on road courses and even dirt tracks. So our cars must be ready for any kind of surface on any kind of track, 38 weekends a year.

We’re holding at around 180 mph normally, with finishes sometimes separated by just 0.01 seconds between first and second place. Pit stops are under 9 seconds. So you can imagine how important precision is.

John Church: IMSA is endurance racing. We run a Porsche 963 hybrid in the Hypercar (GTP) class. Everything in endurance racing is about precision and consistency. We sometimes go through multiple body parts during a race weekend, so everything has to be built to exact specifications to ensure consistency across changes.

We start our season with a 24-hour race, then we do some shorter races that are only 100 minutes long, and we also do medium races that are two hours and forty minutes as well as some six-hour races. So whenever we’re changing parts out, it’s important that the whole car stays consistent from one race to the next throughout the weekend.

Scott Mansell: Let’s get into the technical meat of how your teams run at the top of their motorsport. Being successful in motorsports is all about measurement because you can’t improve if you can’t measure anything. So, how are you using Hexagon tools to improve your performance, both in the workshop and on the racetrack?

Morgan Maia: We use Hexagon in two main ways. First, at the factory. We’re always working with prototypes and don’t have time to test the car before heading to a race. A part might be manufactured on Thursday evening, shipped overnight, and fitted Friday morning for FP1. That means we must be absolutely sure that part is perfect, because we can’t send it back. It has to work immediately with the other 8,000 components on the car.

The second use is for regulations. We send a 3D CAD model of our car, then scan the real car at the track to overlay the two and ensure compliance. If the car isn’t in regulation, we can’t race.

Scott Mansell: So when you bolt the gearbox on, for example, you’re checking everything is perfectly aligned with the engine and chassis. What kind of tolerances are you working with?

Morgan Maia: We’re working with microns. The car is like a watch: everything must be extremely accurate. Even temperature matters. For example, if you start the engine cold, tolerances can be off enough to cause catastrophic failure. So everything must be warmed properly. Micron-level precision is how we find the extra tenths we need to win.

And the drivers feel everything. They can detect a millimeter or even a micron difference. Their feedback can sometimes be sharper than the data itself. Precision gives them confidence to push the car to its limits.

Scott Mansell: Alba, how are you using Hexagon products in NASCAR?

Alba Colón: Well, you’ll find Hexagon tools everywhere in our shop. NASCAR regulations changed a few years ago with the Gen-7 car. Before, we designed and built about 80% of the car ourselves. Now, to control costs, we buy around 80% and only design 20%.

That means we measure absolutely everything we receive: the chassis, the body, all the parts of the vehicle. Everything must be precise. Our Hexagon equipment ensures those parts meet tolerance before going out, since we’re not allowed to bring any of that equipment to the track, so we have to make sure everything we’re taking there is precisely measured.

Scott Mansell: And you’re not just measuring the bodywork, for example, to make sure it’s in tolerance. I’m sure there’s some engineering going on there to try and gain performance by mixing and matching different parts. What’s that like?

Alba Colón: Absolutely, yes. We do a lot of mixing and matching because, for example, this chassis makes more sense to use with that suspension. It’s like a chess game every week, putting together the perfect car.

Scott Mansell: John, what about IMSA?

John Church: In IMSA, when we unload at the track, we go straight to technical inspection. The whole car is scanned, top and bottom, and we’re allowed only a 3mm deviation from the datum.

So before leaving the shop, we scan the entire car and overlay it with the datum to make sure we’re within spec. If something’s off, we fix it before we even load the truck. That saves time and it means less drama with the officials. In endurance racing, everything’s precise until you start hitting things, and then when you need to replace the nose, you want to know each one is exactly the same. Consistency is what matters: your average pace is more important than your fastest lap.

Scott Mansell: Three millimeters sounds like a lot of tolerance when we’re talking about microns, but I’m sure your engineers are thinking, “Let’s go to 2.99999,” so they can get as close to the edge as possible.

John Church: Of course, you’re always trying to push the envelope where you can, but it’s more about making sure everything’s legal and, beyond that, making sure every replacement part that’s going on your car is the same as the last one so the drivers and the engineers have the confidence that it’s the same car as the previous session. If you can’t do that, that’s when the wheels start to fall off the bus.

Scott Mansell: Morgan, you mentioned the incredibly fast development cycles in Formula One. How quickly can you turn around a design to manufacturing and then get it on the actual car?

Morgan Maia: So, again, we always need to have the cost cap in mind, but we also do around a thousand upgrades on the car in a year, so almost all the parts are going to be changed between the first and last phase.

On top of that, setup varies a lot by circuit. If you look at Monza versus Monaco, the car can be almost completely different: same parts, but a completely different car. We push the setup on the track as well.

In Canada, for example, the car fared quite well in Q1, but we didn’t want to leave it at that, because maybe there’s an extra two tenths [of a second] to find. Then in Q2 we find we went a bit too extreme, so we refined again for FP3, still trying to beat FP1. So, there’s a lot of back-and-forth on the track to find the limits of the car and extract all the performance we can from it.

Scott Mansell: These changes you’re making to the toe or camber can make a huge difference in performance and drivability. How often are you making them?

Morgan Maia: There isn’t much time during a race weekend, so a lot happens in the simulator. Our drivers spend days (and sometimes nights) running laps to define the theoretical best setup. Then we reconcile that with driver preference and feel.

Alba Colón: We’re similar regarding simulators, except we can’t make trackside changes with measurement tools like you can. We only get 20–25 minutes of practice, so that’s maybe three changes at most.

At the track, you go through inspection once. If you fail, you get a second chance with the scanner. Fail again and you start losing team members or starting positions, and on some tracks that’s really not great.

Sometimes a driver goes out, does a few laps and then says, “It’s good, so don’t touch it!” And I think that’s because they’re worried we might make things worse if we chase those little changes. Of course, we always want more practice—we used to have two hours!—but now it’s 20 minutes and those are the rules of the game, so we have to do our best to take advantage of what we have in front of us.

Scott Mansell: You mentioned that you’re not allowed to take measurement equipment to the circuit, so what does the process look like when it comes back from the factory? Is it checked then or when it has a new setup for the next race?

Alba Colón: So before the car goes on the track, it goes through a scanner for a 90-second scan that’s mandated by NASCAR. Based on the color map and the tolerances, you’re cleared to race. Then, when the vehicle comes back, we scan it again to see what moved based on what we did at the track.

Within a couple of hours, the whole car is pulled apart and we take photos of measurements of everything to decide which parts will stay and which will be scrapped. By that time, the car that’s going out for the next weekend is already finished and we’re already assembling another vehicle two or three weeks in advance, so there’s constant measurement to make sure everything is working.

Scott Mansell: With such quick turnarounds, the speed of engineering must be critical.

Alba Colón: Very critical. When I left the shop last week, we were already working on the car for a race a month from now, and it’s pretty much ready. So we’re moving parts really, really quickly. If you want a job in racing, and you’re in quality control or manufacturing, trust me: we’re looking for you.

Scott Mansell: John, when your cars come back to the factory, what does that process look like for you?

John Church: Very similar to what Alba was saying. When the car comes back, the first thing we do is scan it just to see how much everything has changed from the start of the weekend. Of course, damage is always obvious, but even where there isn’t any damage, just seeing if anything moved and taking note of it to make adjustments is crucial for going forward.

I think what we’re all trying to do here is control as many variables as we can so that we can guarantee repeatability from one car to the next, one race to the next. That makes everybody’s job a lot easier because it takes the guesswork out of it.

The post Motorsport engineering insights appeared first on Engineering.com.

The report says North American companies ordered 17,635 robots valued at $1.094 billion in the first six months of 2025. Automotive OEMS led with a 34% year-over-year increase in units ordered. Other top-performing segments included plastics and rubber (+9%) and life sciences/pharma/biomed (+8%).

In Q2, companies ordered 8,571 robots worth $513 million, marking a 9% increase in units compared to Q2 2024. Life sciences/pharma/biomed posted the strongest sector growth in the quarter (+22%), followed by semiconductors/electronics/photonics (+18%) and steady gains in plastics, automotive components, and general industry.

 “It’s not just about efficiency anymore. It’s about building resilience, improving flexibility, and staying competitive in a rapidly changing global market. If these patterns hold, the North American robotics market could outperform 2024 levels by mid-single digit growth rates by the end of the year,” said Alex Shikany, Executive Vice President at A3.

Cobots’ rising influence

Collaborative robots (cobots) accounted for a growing share of the market with 3,085 units ordered in the first half of 2025, valued at $114 million. In Q2, cobots made up 23.7% of all units and 14.7% of revenue. These systems work safely alongside humans and address automation needs in space- or labor-constrained environments. A3 began tracking cobots as a distinct category in Q1 2025 and will expand future reporting to include growth trends by sector.

Automotive versus non-automotive sectors

The non-automotive sector took the lead over automotive in Q2, accounting for 56% of total units ordered. This move reflects the expanding role of automation in industries such as life sciences, electronics, and other non-automotive manufacturing sectors.

The post Report shows steady automation investment in first half of 2025 appeared first on Engineering.com.

Why is HIL testing important in automotive engineering?

In recent years, the number of electronic control units (ECUs) in automobiles has grown dramatically. These ECUs have replaced many mechanical components and handle various functions and input/output, making them prime candidates for HIL testing. By simulating the operation of ECU-guided automotive products, teams can test virtual representations of products instead of physically testing finished prototypes.

HIL testing offers numerous benefits to automotive engineers. By testing virtual models of products, teams can save significant time and expense. HIL testing can also identify potential flaws earlier in the workflow, when the flaws can be fixed more affordably and efficiently. And, with virtual models replacing physical models, HIL testing can consider numerous scenarios without the time and expense required for physical tests. It also offers safety benefits, enabling teams to simulate conditions without exposing humans to dangerous situations.

Examples of automotive HIL testing

A wide variety of automotive products and systems can benefit from HIL testing. While some systems include interaction with the user and others are controlled automatically by sensors and computer-aided devices. If over-the-air (OTA) updates are provided to update software, HIL testing can also incorporate these updates and modify testing accordingly. Here are some examples:

Engines: One or more engine ECUs govern engine operation, converting sensor measurements into actions such as adjusting air intake. HIL testing simulates engine operation and interaction with real I/O devices such as acceleration pedals. For internal combustion engines, this might include testing controllers that handle fuel consumption and emission control. For electric vehicles (EVs), HIL testing might simulate a motor-generator, battery and connections to direct-drive transmission.

Powertrains: Transmission systems, power electronics and battery management systems can be tested with real-time simulations. HIL testing simulates the operation of various components such as converters, relays, onboard power system components and charging systems. With the growth of EVs, battery management is a key design consideration.

Chassis and vehicle dynamics: This can include steering, braking, suspension and traction control systems. For example, a steering system can be tested using HIL techniques to model  vehicle handling behavior based on digital input that simulates steering wheel actions. The testing can aid development of steering controls and electro-mechanical actuators. Similarly, brake hydraulics can be simulated with HIL testing to model braking maneuvers and vehicle responses.

Advanced driver assistance systems (ADAS): Cameras, sensors and other devices can help alert drivers of potential collisions with other vehicles, detect pedestrian and roadside obstacles, and in the case of autonomous vehicles (AVs), take over driving under certain conditions. HIL testing can simulate real-life situations in developing and validating these systems.

Interior features: Seating, lighting, heating, air conditioning and other systems now rely heavily on ECUs. HIL testing can be used to test scenarios such as power-seat operation and climate-control systems, which may include heat exchangers, compressors, sensors, actuators, ductwork and other devices. HIL testing can simulate the functionality of various components and ECUs and their connection to the centralized ECU.

Entertainment and information systems: These systems connect the driver and passengers to a wide variety of information sources, including mobile devices, conventional and satellite radio, cloud resources, dashboard display systems and diagnostics. They also play a key role in coordinating OTA updates. HIL simulation can test various instrument clusters, displays and warning systems, with a real-time target machine running a virtual vehicle and direct interfaces using analog and digital signals or standard communication protocols.

What other types of testing are used with embedded systems?

In addition to HIL testing, various other types of testing are used in embedded automotive systems:

• Model-in-the-loop (MIL) testing simulates both the controller and the physical systems with virtual models instead of physical hardware. MIL testing is often used in early development stages to verify design assumptions and control algorithms.
• Software-in-the-loop (SIL) testing runs the software in a simulated environment to verify that the control algorithms are operating correctly, providing a bridge between model simulations and real-world applications.
• Processor-in-the-loop (PIL) testing executes the control algorithms on the actual processor or other device connected to the simulated environment. This technique checks for potential issues related to code generation, execution timing and processor-specific behavior, confirming that the software will perform as intended.

Several variations of HIL have also been developed. Power hardware-in-the-loop (P-HIL) testing introduces power amplifiers or other power equipment to convert low-voltage signals from a real-time system into the higher voltages of the emulated device. This approach enables teams to test power components of the control system in a framework similar to actual operating conditions.

Virtual HIL (vHIL) testing enables creation and execution of tests before the actual ECU hardware is available. With the vHIL approach, testing can begin earlier and be automated to guide subsequent testing.

What standards are applicable to HIL testing?

A variety of standards and guidelines apply to automotive HIL testing. The International Organization for Standardization (ISO) established ISO 26262 (road vehicles functional safety) as an international standard for functional safety of electrical and/or electronic systems. ISO 26262 includes requirements for HIL development processes and documentation of these processes, as well as qualification and validation. Other ISO standards applicable to automotive testing include ISO 21448 (road vehicles — safety of the intended functionality or SOTIF) and ISO 21434 (road vehicles cybersecurity engineering), which was developed in conjunction with SAE International.

The Association for Standardization for Automation and Measuring Systems published ASAM XIL, an API standard that covers multiple types of in-the-loop testing, HIL, MIL and SIL. The standard provides guidance on communication between test automation tools and test benches, facilitating the integration of HIL technology from different vendors.    

Various communication protocols apply to HIL testing. Protocols such as Ethernet, controller area network (CAN) and local interconnect network (LIN) define connections between the real-time test system and the actual embedded controller. Actuator interfaces that connect the test equipment to the simulated system use these communication protocols to accurately capture hardware responses and feed them back into the simulation for real-time analysis.

Future applications of automotive HIL testing will likely incorporate artificial intelligence (AI), automation and digital twins. AI and automation can help improve efficiency, simulating driver behavior, traffic conditions, and other complex situations. Digital twins — virtual representations of physical systems — can enhance the realism of HIL simulations, allowing for real-time synchronization between virtual and physical components.

HIL testing is also likely to become more modular and scalable, allowing for testing of different vehicle types. This enables testing to be adapted to a wide range of vehicles, ranging from compact cars to luxury sedans and commercial vehicles.

The post How is hardware-in-the-loop (HIL) testing used in automotive engineering? appeared first on Engineering.com.

This is not just a transaction between two legacy software firms. It could represent a redefinition of the industrial software landscape: Autodesk, long focused on democratizing design via the cloud, meeting PTC, grounded in enterprise-scale digital transformation for manufacturers. The overlap is clear. The complementarity? Still to be proven.

Strategy, scale, and ambition

While both companies are respected in their domains, they differ significantly in size, culture, and strategic posture:

• Autodesk reported more than $6.1 billion in FY2025 revenue (fiscal year ending January 2025), with a market cap of approximately $66.6 billion.
• PTC reported $2.3 billion in FY2024 revenue (fiscal year ending September 2024), with a current market cap around $17 billion following the takeover speculation bump.

Autodesk is more than twice PTC’s size in revenue and has traditionally focused on AEC, creative design, and mid-market engineering. PTC, in contrast, is deeply rooted in industrial manufacturing, PLM, and IoT.

This is not a merger of equals. It reflects Autodesk’s strategic ambition to move deeper into the enterprise market. With PTC, Autodesk would gain credibility and capability in core enterprise workflows. This would mark a step change for Autodesk’s portfolio maturity—from cloud-native tools for SMBs to enterprise-scale digital thread and product lifecycle platforms.

Yet, the companies have very different go-to-market approaches. Autodesk has built its SaaS business around high-volume channels, while PTC’s sales motion is enterprise direct. That contrast creates opportunity-but also serious integration risk.

Market reactions and community feedback

PTC shares surged over 17% on July 9 after Bloomberg reported Autodesk was exploring a bid. They fell 7.5% the next day. Autodesk’s stock declined nearly 8% as investors assessed the strategic rationale and integration risks. These market movements highlight the scale and sensitivity of such a transformative bet.

In professional forums and industry circles, the deal has sparked debate. Many experts have expressed skepticism about strategic alignment. They point out potential redundancy between core CAD offerings (Creo vs. Inventor/Fusion 360) and PLM solutions (Windchill vs. Fusion Manage). Others note Autodesk’s limited experience in large, complex integrations, and voice concerns about its ability to manage an enterprise-scale acquisition.

One clear thread: this would be a high-risk, high reward move. Autodesk has never made a deal of this magnitude. It could unlock new verticals—but also strain its operating model and alienate parts of its existing base.

Analysts also speculate on regulatory hurdles. The CAD and PLM market is already concentrated. A deal of this scale may face antitrust scrutiny, particularly in the US and Europe. Financing would also be a stretch, and shareholders will expect a well-articulated synergy plan. The rumored price tag of about $20 billion raises the stakes further.

Product portfolio and strategic fit

Autodesk has invested heavily in Autodesk Platform Services (APS), with Fusion 360 acting as its design collaboration anchor. PTC’s portfolio is broader in manufacturing and enterprise engineering, with Windchill+, Arena (PLM), Onshape (cloud CAD), and ThingWorx/Kepware (IoT/edge connectivity).

While the combination would offer end-to-end coverage from SMB to enterprise, the breadth creates duplication. Customers may worry about future roadmap clarity. Will Autodesk continue Fusion Manage or prioritize Windchill+? Can Creo and Inventor coexist? And does Autodesk have a plan for ThingWorx and Kepware, which do not align with its core portfolio?

Most experts believe those IoT assets will be divested. That opens new opportunities for companies like Rockwell, Schneider Electric, or Emerson—firms more focused on industrial automation and edge connectivity. These decisions will send strong signals to the market about Autodesk’s long-term intent.

Beyond the technology, there is a broader question: is Autodesk acquiring products, a platform, and/or an extended customer base? The answer is likely to be multiple. It will determine how much integration effort is required—and how much customer disruption it might cause.

Execution and leadership will define the outcome

The true test will be execution. Autodesk has evolved into a cloud-first player over the past decade, but it has little experience with large-scale enterprise integrations. PTC, though smaller, brings a strong industrial culture and a distinct go-to-market strategy that may not align with Autodesk’s creative, SMB-rooted DNA.

Cultural integration, pricing model alignment, and partner ecosystem rationalization will be complex. If poorly managed, these differences could erode customer trust and delay value realization.

Leadership will play a pivotal role. PTC’s new CEO, Neil Barua, took over in February 2024 from long-time chief Jim Heppelmann. Barua, formerly CEO of ServiceMax (acquired by PTC in 2022), brings a sharper focus on customer-driven innovation and return on investment. His strategic priorities—and openness to integration—could influence how the two companies align.

ThingWorx and Kepware, once central to PTC’s digital transformation narrative, now appear most vulnerable to divestment. Their fate may define Autodesk’s long-term industrial strategy. Rockwell Automation’s recent exit from its $1B stake in PTC in August 2023 further suggests shifting alliances and possible competitive realignments in the broader industrial software ecosystem.

This deal, if it proceeds, will not go unnoticed. Siemens, Dassault Systèmes, and other PLM leaders are likely already reassessing their positions. A successful integration would escalate the digital thread race. A failed one could reinforce the limits of M&A in an already saturated market.

In the end, the acquisition is just the beginning. The real transformation will be defined by what Autodesk chooses to keep, integrate or let go.

Editor’s update July 14 2025: In the days after this story was published Autodesk in a regulatory filing declared this deal is no longer on the table and will instead focus on more strategic priorities, as reported by Reuters.

The post Autodesk mulling PTC takeover to create industrial software juggernaut appeared first on Engineering.com.

On June 12, 2025, VI-grade hosted the North American Zero Prototypes Day at its SimCenter in Novi, Michigan, located within Multimatic’s facility. This day piggybacked on the company’s international Zero Prototypes Summit event in Udine, Italy, held in May. Videos of each presentation are available online, but here are some key takeaways from experts and exclusive interviews.

Virtual and physical testing are two sides of the same coin

“It’s quite clear that the industry is moving at a rapid pace towards virtualization,” said Omar Elsewify, chassis development engineer (Vehicle Dynamics) at Hitachi Astemo. “OEMs are pushing more and more for their suppliers to match their agility in terms of virtual capabilities. More and more, we’re seeing OEMs ask their suppliers to be involved in the validation and integration stage, as well as virtually developing and virtually validating. As those virtual requirements have increased for validation, so have the testing requirements, and what used to be acceptable in terms of just providing software-in-the-loop validation has now increased the requirements to provide hardware-in-the-loop capabilities, driver-in-the-loop capabilities, as well as vehicle-in-the-loop capabilities, in some cases.”

Astemo developed a high-fidelity AI-MBD damper model as a software-in-the-loop solution that runs in real time and captures real-world dynamics. The company uses VI-grade’s Full Spectrum Simulator (FSS) to validate the model with hardware-in-the-loop and driver-in-the-loop simulations.

“The damper for them is real, because in the end, they have to come up with a real product. But very often, they don’t have a real car, so they use a virtual vehicle model and perform an auto-in-the-loop simulation, in which you have the damper in the loop with everything else,” said Guido Bairati, VP of global sales at HBK (VI-grade’s parent company) and former managing director at VI-grade. “The driving simulator has the great advantage of putting the driver in the loop into the equation, so you can easily test your component with a real driver.”

Simulators are game-changing for design and development cycles, helping engineers test everything from components and powertrains to human-machine interfaces (HMIs), driver comfort, and more. David Trumpy, senior principal software engineer at Harmon Becker Automotive Solutions, discussed how his team integrates their sound design library in a VI-grade noise, vibration, and harshness (NVH) simulator, which stakeholders use to evaluate and provide feedback for future iterations.

“The simulator is sending the control data over to our library, and we send the audio samples back, so it’s added in just like another layer or another sound component. We find that the desktop simulator enables our team to manage multiple configurations, so they can switch between different versions, different software releases by using different sound objects,” said Trumpy. “We can share these sounds across team members. We have team members around the globe working on sound design and feature development, and then we can test over a wide array of use cases, like fixed driving modes. In the fixed driving mode, we can use playback from a recorded vehicle, and in free driving mode, we can interact with the vehicle like a driver in the loop. We can also live-tune our algorithms while we’re running in the simulator. So we can connect our tuning tool directly to our algorithm while it’s running and change parameters and hear the difference live in real time.”

Trumpy admitted that they aren’t ready to give up their test vehicles due to differences between the simulator setup and vehicle testing. He noted that data in the simulator can be overly idealistic, so high-fidelity powertrain models are essential for tuning algorithms, as well as testing a wide range of driving scenarios.

Though the goal of zero prototypes is to produce a first car that can be sold and driven off the lot, Bairati reminds us that virtual testing and physical testing are two sides of the same coin. Yet, virtual testing technologies go beyond cool features and cost savings and now ensure survival in this increasingly competitive global market that pushes companies toward virtualization.

“The industry is seriously pursuing zero prototypes to reduce costs and delays, with companies aiming for 100% virtual development,” said Bairati. “This urgency is particularly pronounced in China, where rapid development cycles are becoming the norm. They are talking about developing a car in 12 to 18 months. If you want to really develop a car in one year, there is no way but virtual.”

This technological evolution is fundamentally changing how engineers work, shifting from the traditional sequential V-cycle process to more iterative approaches.

“We are moving from a sequential type of development to more parallel development, enabled by continuous testing loops that provide faster feedback and more agile development cycles,” said Bairati. “Physical testing will not disappear, but it will change, and it will be used to create better virtual models. And then the virtual models will be used to optimize the physical test that you have to do at the end of a development cycle.”

Advanced simulators help speed up development

Admittedly, using a vehicle simulator is a fun experience, but the technology is significantly more advanced than any arcade game and is designed to collect specific, real-time data for engineers to improve and innovate.

“Our mission is to help you win the zero prototypes challenge, to help you innovate faster. And we do that through a combination of driving simulators, simulation software, and HiL systems,” said Dave Bogema, senior director of product management at VI-grade.

Two years ago, VI-grade announced its Compact FSS, which combines vehicle dynamics and NVH in one simulator. Last year, the company took another step forward by launching its Driver-in-Motion Full Spectrum Simulator (DiM FSS), which provides six degrees of freedom for a highly immersive experience, allowing engineers to evaluate several vehicle attributes simultaneously.

“Over the last 10 years, we have been developing simulators with higher peak accelerations, lower latency, and improved dynamics overall. This year, we’re announcing the next step in that evolution, the HexaRev,” said Bogema. “It’s a six-degree-of-freedom motion platform unlike any other.”

The design is simple, with six motors connected directly to the cockpit. There are no ball screws, gears, belts, chains or anything that could create extra noise or vibration. The system is quiet and provides an immediate response.

“When you have a traditional six-degree-of-freedom system, as you have multiple degrees of freedom active at the same time, your overall motion envelope kind of shrinks,” said Bogema. “The HexaRev maintains a much larger overall motion envelope, so it gives you a much bigger dynamic space to work with. If you combine the HexaRev with the Hyperdock, which is our carbon fiber cockpit that we launched last year, this turns it into an FSS simulator, able to simulate that whole range from zero to 20 kilohertz.”

This year, VI-grade also launched the Compact HMI, a highly configurable simulator that can switch between multiple cockpit configurations using a touchpad. It also serves as a real-time driving simulator, allowing the vehicle to be tested in various environments and scenarios, and to evaluate HMI concepts.

“When you’re evaluating HMI concepts, you really need the driver in the loop, because at the end of the day, it’s the driver who decides whether that HMI is good enough,” said Bogema.

Prioritizing humans in an AI-driven future

As vehicle design becomes increasingly complex, and engineers must design, develop, and test faster, VI-grade launched VI-DataDrive Cloud to help engineers extract insights from data quickly.

“VI-DataDrive Cloud is focused on VI-CarRealTime. If you look at how we normally use VI-CarRealTime, you would sit at a workstation, build your models, design your tests, run those simulations at your local workstation, and then analyze the results again at that local workstation,” said Bogema. “What we’re doing here is changing that paradigm, still allowing you to design the test at your local workstation, but then upload to the cloud and run lots of simulations in parallel. What this enables you to do is process a lot more data.”

The solution also enables engineers to share data rapidly, collaborate more effectively, and make decisions faster. As Bairati mentioned, making sense of data is key for iterative development.

“Primarily, what I see is customers struggling with a large amount of data. All customers are telling us that generating data is not an issue. They actually generate from a virtual and physical test more data than they are able to manage,” he said. “The issue they have is how to make that data available within the organization and to look into the data. In the near future, there will be AI agents who are looking into data and telling engineers in which direction to go for the next development step.”

Bairati also said the ultimate goal is to create digital twins that can be continuously updated with real-world fleet data. And though AI isn’t yet widely used, it’s emerging rapidly and will eventually become ubiquitous in the virtual testing and vehicle development process.

However, AI won’t usurp human jobs and expertise. In fact, Iain Dodds, VI-grade’s technical director in North America, cautions against unchecked reliance on AI and even reliance on people who lack domain knowledge.

“You get people who don’t understand the domain coming in and just take it from a pure data perspective. And that gets scary,” said Dodds. “You’ve got to make sure the conclusions you get from your data are valuable and relevant, and not just data for data’s sake.”

Dodds demonstrated the VI-WorldSim graphics environment and explained how the product has matured, yet they’re just scratching the surface of its capabilities.

“WorldSim can create a graphics data feed from a sensor. It can simulate a sensor, camera, radar, LiDAR, and the quality of the data coming out can actually be used to do ADAS development,” he said.

Engineers can use WorldSim for data generation and algorithm validation, and can even integrate hardware components into the simulation. “The simulation is getting that good,” Dodds said, yet the technology adoption requires trust in the model and trust in the people developing the algorithms. Greg Stevens, research director of Mcity at the University of Michigan, addressed this during his presentation on “the curse of rarity.”

“If you have an autonomous vehicle, today it’s basically being driven with AI algorithms, and AI algorithms are really good at handling situations that they’ve seen before. They’re not really great right now at adapting to novelty, to situations they haven’t seen before,” said Stevens. “That’s where the curse of rarity comes in because the goal is to get enough training data to train your AI algorithm properly.”

Normal driving data is a dime a dozen. Engineers can collect data at any time of day or night to capture normal conditions. As Stevens noted, the challenge is “the safety-critical and near-miss data.” Accidents, especially fatal accidents, are considered rare, which makes it difficult to simulate physically.

“It just doesn’t scale. Simulation has to be part of the solution here,” he said.

Next steps on the zero prototypes journey

In addition to AI advancements and faster, more interactive design and development cycles, Bairati emphasized the growing importance of multi-attribute simulation for virtual testing and vehicle development.

“Historically, there were simulators for different disciplines. Think about Formula One. They only care about vehicle dynamics. They only care about lap time. They don’t care if a car is noisy or not,” Bairati said. “But customers are asking us for simulators that are able to study how the car handles, how the car rides, and how the car sounds, or the tire, not just the car, but also components at the same time. Because when you drive your car, you experience all these different attributes together simultaneously. You care about how the car handles on a winding road, but at the same time, you also enjoy if a car is silent and how it rides. So, we at VI-grade put a lot of effort in the last three to four years to have a multi-attribute simulator where you can study all different disciplines.”

To move such advanced technology forward, partnerships will continue to be a priority, such as that of VI-grade and Multimatic.

“Our relationship with VI-grade dates back decades,” said Peter Gibbons, technical director of vehicle dynamics at Multimatic. “Fifteen years ago, we commissioned the first viable simulator for vehicle development, and that happened in Toronto. From then on, it’s continued to the point of doing this cooperative relationship here, where basically VI-grade and Multimatic are joined as one for this facility.”

John Kipf, engineering director of operations at Multimatic, added that the partnership has many successful years ahead.

“We’ll continue to grow, particularly as we do a lot of ride-based things within the vehicle dynamics sphere, it’s an opportunity for us to explore and do more in that,” Kipf said. “That’s really how this place came to be. It’s been really good, and we support each other as much as possible.”

To learn more about VI-grade and Multimatic’s SimCenter Detroit, visit
vi-grade.com/en/services/simcenters/simcenter_detroit.

The post Virtual testing is transforming automotive engineering appeared first on Engineering.com.

Arena SCI continuously checks for emerging risks from evolving supply chain conditions, embedding real-time AI-driven component monitoring and risk mitigation insight directly into product development workflows. The goal is to manage component risks throughout the entire product lifecycle within and existing PLM environment.

Product development and introduction teams use Arena SCI to continuously monitor electronic components across bills of materials (BoMs) to identify emerging risks from changing supply chain conditions. Arena SCI then suggests alternative components based on technical compatibility to prevent sourcing interruptions before they impact production.

“By delivering supply chain intelligence directly where design decisions are made in a cloud-native environment, Arena Supply Chain Intelligence simplifies collaboration between design teams and suppliers and supports more proactive component sourcing decisions to help offset supply chain disruptions,” said David Katzman, General Manager of Arena and Onshape, PTC. Katsman says PTC’s investment in SCI adds a new dimension that prioritizes resiliency and hinted at more AI-driven functionality in future arena releases

Arena SCI works by using electronic component data from information services provider Accuris to outline comprehensive electronic risk details and suggest alternative parts.

“Our teams face constant pressure to move faster, even as supply chain challenges become increasingly unpredictable. We are seeking ways to help us stay ahead by identifying risks early and avoiding costly last-minute changes, so we can keep projects on track and deliver on time. We see Arena SCI as an opportunity to help achieve this,” said Dan Freeman, Director of Hardware Engineering, Universal Audio.

Since its acquisition by PTC in 2021, Arena has expanded into new international markets, introduced over 16 product releases, It collaborates with PTC’s Onshape cloud-native computer-aided design (CAD) and product data management (PDM) platform, resulting in a cloud-native CAD-PDM-PLM offering to support cross-functional product development

The post PTC adds supply chain intelligence to Arena PLM appeared first on Engineering.com.

By Joseph Carew

Avoiding the rare raw materials required for the production of traditional batteries without sacrificing energy density is a major goal for those looking to electrify the world. Lithium-ion batteries power most of today’s electric vehicles (EVs)¹ but are associated with high costs as well as sustainability and environmental concerns. Engineers and developers in the battery industry are investigating alternative chemistries and designs to find new approaches that address these concerns and reduce costs while fulfilling the demands of most lithium-ion applications.

IAV is one of the world’s largest engineering companies. Within an extensive portfolio geared toward the future of mobility, battery development plays a critical role. A team of IAV engineers including Jakob Hilgert, a technical consultant at the company, felt that, with the right approach, IAV could achieve better battery designs. The team leaned on its understanding of what makes existing single-chemistry designs successful — as well as what holds each back — to develop a novel approach to solving battery energy density, sustainability, and thermal management issues: a twin-battery design.

Instead of turning solely to lithium-ion cells, IAV engineers thought a pair of alternative battery chemistries could be combined to form a less expensive and more ecofriendly system that could handle EV applications. With this approach in mind, IAV turned to multiphysics simulation to successfully design and validate its twin-battery solution.

Avoiding Lithium-Ion Battery Pain Points

While lithium-ion batteries (Figure 1) are often used for their high energy density², their creation can have environmental drawbacks. Open-pit mining for lithium removes vegetation, creates toxic soil, and releases dust that elevates the risk of illness in animals and people³. Producing these batteries is also an expensive prospect¹ and reliant on a relatively rare material. IAV engineers looked to avoid these concerns when choosing the technologies to be included in their twin-battery approach.

“We need to be prepared for batteries that have a larger focus on recycling and resources,” Hilgert said. “We cannot always take the highest-energy-density cell that is theoretically possible and use that as our solution.”

Instead, the team at IAV chose to pair a sodium-ion battery (SIB) and a lithium iron phosphate (LFP) solid-state battery (SSB) for its design because of the chemistries’ unique ability to complement one another. SIBs are typically cheaper, more sustainable to source, and easier to recycle than conventional lithium-ion batteries⁴; however, they tend to have comparatively lower energy density and a shorter cycle life. Meanwhile, traditional LFPs are known for their stability and long cycle life but also lack in energy density when compared to conventional lithium-ion batteries. Finally, SSBs are known for having higher energy density than traditional lithium-ion battery chemistries. By combining an SIB with an LFP-SSB, the resulting design should theoretically have an improved environmental footprint (Figure 2), cost less money to create, and feature a relatively strong energy density for demanding applications such as powering EVs.

“The development of batteries for automotive use is progressing rapidly. It goes hand in hand with a rising demand for scarce raw materials,” Hilgert said. “Diversification of cell chemistries is a promising approach to respond to market fluctuations and at the same time minimize system costs.”

Creating Thermal Compatibility

IAV’s twin-battery design was also developed, in part, to test the thermal compatibility between an SIB and LFP-SSB. The idea was that channeling the waste heat from the SIB into the LFP-SSB would rapidly activate the latter’s solid-state cells and push them into the higher temperature ranges where they perform best⁵ — while simultaneously keeping the SIB from exceeding its maximum operating temperature and increasing the system’s overall energy efficiency.

“If we have some cells that can operate at high temperatures and some cells that can operate at low temperatures, it is beneficial to take the exhaust heat of the higher-running cells to heat up the lower-running cells, and vice versa,” Hilgert said. “That’s why we came up with a cooling system that shifts the energy from cells that want to be in a cooler state to cells that want to be in a hotter state.”

Cells with liquid electrolyte have limited thermal stability and require cooling (true for both sodium and lithium cells), and temperatures above ~60^°C need to be avoided. Solid-state cells can operate at higher temperatures because of their solid electrolyte, and these need an elevated temperature to reach usable ion conductivity. Therefore, the SIB cells in this concept need cooling while the SSB cells need heating, and both cells benefit from the mutual heat exchange. IAV engineers knew that this interaction in particular would be a significant optimization challenge and felt that modeling and simulation would be essential to easing the complexity. For this, the team turned to the COMSOL Multiphysics^® software.

Designing the Battery System

IAV first began using COMSOL Multiphysics^® more than a decade ago to improve its design workflow.

“We were using a large quantity of different specialized tools for different specialized topics,” Hilgert said. “When we started working with batteries, it was time to say, ‘We need one tool to deal with all of these topics.'”

The platform’s comprehensive workspace gives IAV the opportunity to avoid building unnecessary prototypes for clients and easily optimize its designs. With the twin-battery model, IAV engineers can tweak different parameters (whether, for example, they impact the cooling of particular circuits or the maximum power that cells at a certain temperature produce) and alter the design to ensure that any real-world creation is as efficient as possible. “If you have this knowledge and you do not have to guess at all of these parameters, then the technology readiness level of the prototype will be a lot higher,” Hilgert said.

Because of the multiphysics nature of battery modeling, the COMSOL^® software’s capabilities were well suited for the twin-battery system (Figure 3) development project: Designing operational batteries requires proper thermal management, an understanding of how the materials of different cells are going to perform within their modules, knowledge of the varying pressures within the internal processes in the battery, as well as an electrochemical understanding of the whole. There also needs to be an understanding of how swelling or contraction during charging and discharging can impact the mechanics of these systems. “A highly integrated model-based development process can be used to investigate the potential of different cell chemistries, designs, and cooling concepts,” Hilgert said. “It reduces the need for physical prototypes and allows for performance optimization toward typical requirements of automotive applications.”

Heating, Cooling, and Design Optimization

Engineers at IAV were able to verify the performance of its twin-battery concept using coupled multiscale and multidomain simulation (Figure 4). The team found that the design worked as desired during concept development, paving a path forward for better battery design. The model showed very fast on-demand activation of solid-state cells, with partial preconditioning done by the SIB’s waste heat. The team has optimized the thermal management of the two cells and shortened the time and energy input needed for SSB activation in cold conditions. “The simulations showed that it is actually possible to do what we had in mind,” Hilgert said. “The waste heat actually can be transported by the cooling system, and the amount of heat is sufficient to heat up the other part of the battery.”

IAV was able to run different scenarios, comparing various levels of sensitivity for different surrounding conditions or parameter selections with its model, which functions as a virtual prototype. The team successfully integrated 3D cell temperature distributions, pseudo-2D (P2D) electrochemical modeling, and 1D cooling circuit dynamics into a comprehensive electric powertrain model.

Democratizing the Twin-Battery Model with Apps

Once IAV’s simulation specialists have developed a white-box model for a customer, they often use the Application Builder in COMSOL Multiphysics to additionally package its functionality into a simulation app, a custom-configured user interface with restricted inputs and outputs that the customer can distribute internally to colleagues in different domains who use it to run simulations and evaluate results in their respective contexts. App users do not need in-depth knowledge of the underlying complex model; instead, simulation apps are designed to be easy to use and hard to break, making them ideal for IAV’s many customers who “want to distribute these simulation tasks to people that usually do not do modeling,” as Hilgert put it.

“We can start with the basic functionality and hand it out to everybody, and nobody will have a problem using it. Later on, if things get more detailed, we can have the apps grow with the application and add more physics, more options, more buttons,” shared Hilgert.

IAV engineers use COMSOL Compiler to turn their simulation apps into standalone executable files that they send to their customers alongside the white-box versions of the underlying models, who can then run them without a COMSOL license (Figure 5). This makes it easier to run simulations in distributed development environments. In the case of the twin-battery design, cooling system engineers can run parallel optimization calculations without COMSOL licenses. Streamlined access to simulation results leads to more efficient development processes and has greatly improved the acceptance of model-based development both internally and among IAV’s customers.

“Having COMSOL Compiler as a distribution option is a great benefit for our work,” Hilgert said. “We can use our own models for some simulation or profiling tests just by compiling some apps and then having other people do their jobs, without having to wait for the licenses.”

Interfacing Java code is used to provide remote control of the apps that IAV builds thanks to the COMSOL software’s API. This remote control allows users to automate repetitive modeling steps. The team also implements Functional Mock-up Unit (FMU) interfaces, which it couples to vehicle simulation environments in third-party software for cosimulation.

Users of the twin-battery app are given the voltage, state of charge (SOC), temperatures, and power dissipation as inputs to the battery management system and cooling system. Design engineers can view the internal cell states through these apps and make changes to the cooling system as they evaluate the varying battery performance.

Using Apps Internally

Apps that are used internally at IAV are often designed for cosimulation with COMSOL Multiphysics^® and external toolchains and are routed through IAV‘s virtual test bench interface. Figure 6 shows an example battery module app used for cosimulation, which provides basic user feedback about the internal states of the models like current, voltage, temperatures, etc. App results are provided as a real-time data stream to other programs in the cosimulation framework, where detailed evaluation of results is performed.

(T)Winning the Battle for a Better Battery

IAV hopes that its twin-battery design concept will function as a showcase to others in the battery industry that, even if you have demands that are contradicting, there can still be a solution.

“The twin-battery approach gives the car manufacturer or the battery designer more options to solve their problems,” Hilgert said. “It also shows that there is a way of integrating future technologies with very different principles into existing frameworks.”

Learn more about simulation apps in this resource: www.comsol.com/benefits/simulation-apps

References

1. “Batteries for Electric Vehicles,” Alternative Fuels Data Center (AFDC); https://afdc.energy.gov/vehicles/electric-batteries
2. “Lithium-Ion Battery,” Clean Energy Institute, University of Washington; https://www.cei.washington.edu/research/energy-storage/lithium-ion-battery/
3. “Environmental Impacts of Lithium-ion Batteries,” UL Research Institutes,16 Mar. 2022; https://ul.org/research-updates/environmental-impacts-of-lithium-ion-batteries/
4. “Sodium-Ion Batteries,” Battery Research & Innovation Hub; https://batteryhub.deakin.edu.au/battery-storage/sodium-batteries/
5. D. Murden, “LiFePO4 Battery Operating Temperature Range: Safety, Precautions, and Common Mistakes,” Eco Tree Lithium, 24 Apr. 2023; https://ecotreelithium.co.uk/news/lithium-iron-phosphate-battery-operating-temperature-range/
6. M. Sens et al., “Towards a Sustainable Vehicle Concept Part 1: The High-Voltage Battery – Technologies and Methods,” Austrian Society of Automotive Engineers, 2023; https://oevk.at/en/papers/189d672b-9b1f-4aa3-ba4f-3915871336e3

Oracle and Java are registered trademarks of Oracle and/or its affiliates.

Sponsored by Comsol

The post Driving EV Development with a Twin-Battery Approach appeared first on Engineering.com.

Throughout my career, I have had exposure to several types of legacy software in different companies and industries. Organizations deal with the idea of transforming to a digital platform in one of three ways: they view the legacy software as crucial and must be integrated (high resistance), they keep using it in parallel to a digital approach regardless of the high cost, or they transition completely to a digital system, which is surprisingly the least common approach.

During my time working for a global automotive company, I encountered a semi-collaborative approach to data sharing and working together. The main problem for engineering was working together in a private ecosystem. This was caused by several factors— different rules and regulations at each location, legacy software and a legacy mentality driven by several acquisitions that were never fully integrated. Our north star became the migration to a digital platform that bridged the divide and got the locations to work together. This approach was ultimately successful, and members of the organization could easily work on their projects from any location.

 Of course, issues appeared with the transition to a digital thread, including numbering schemes and streamlining or adapting processes to local needs. I learned that it is very easy to fall down the rabbit hole if you entertain every little detail. Instead, your main drive should always be to the agreed scope. During this transition, I had to quell a lot of debates on minor things that could have derailed the scope of our projects, and there were a lot of projects in the initial phase, such as our desired outcomes from moving to a complete digital thread, which software to migrate or discontinue, vendor selection and many others.

Indeed, it’s worth taking time at the beginning to design your solution as thoroughly as possible—it saves a lot of headaches down the road and most importantly, saves money. The role of an engineer in this specific spot is to balance out the budget with features. First and foremost, in this role you must bridge the divide between design and manufacturing, this was one of the first things that I learned as I was cutting my teeth in my first engineering job. You can design a product or a solution as neat as possible, but at the end you must produce it and to produce a product is a whole other beast than just drawing it on your computer. Understanding both the design component and having a surface understanding of how the product is manufactured gave me enough credit with the shopfloor people that I became the go to person for the head of manufacturing to present their topics and work with them to be able to incorporate them in the implementation process.

One of the most important but frequently ignored topics is user acceptance. People who are working with a specific software are usually SME (subject matter experts) and know the software in detail. Because of this, it can be tough to gain buy-in, but they are your most important asset in a legacy software to digital thread transformation. They have depth of knowledge that is critical to a successful migration or transition. Who knows LS outputs? Who knows how the processes were designed? Who knows which person down the process needs to be informed? The subject matter expert will make your life a thousandfold easier, so include them as early as possible, align on scope and have them help you build it.

If I were to choose one thing to avoid at all costs during a digital transformation, it would be ignoring parts of the organization. My success in this project was a result of the frequent consultation with the people handling day-to-day business of the organization. Since we started with several locations during ramp up, we ended up working very closely with people from all over the production process. This resulted in rapid feedback on anything that we did—especially on what we did wrong. That feedback is crucial, as we could incorporate it and adapt from sprint to sprint.

Legacy software is still present in many companies, but it should not be seen as malign pieces of a process that would kill a project before it starts. Rather, it was an important piece of the puzzle that fit the organization at a specific time in its existence, and as organizations mature and digital becomes the new norm, legacy software should be considered an important aspect of a migration scenario, even if it will ultimately be replaced.

Andrei Lucian Rosca is an engineer with a bachelor’s in mechanical engineering focusing on CAD software with more than 10 years of experience in Digital Transformation projects in several industries, from automotive to consumer goods. I am currently exploring innovative solutions (e.g. IoT, AI) and how to include them in future projects.

The post Dealing with legacy software during a digital overhaul appeared first on Engineering.com.