- IMCO Industries, an Israeli defense contractor, has secured a new contract with the Israeli Ministry of Defense for software-defined armored vehicle systems.
- IMCO supplies electrical systems, mission computers and smart displays for Israel's Merkava tank and Namer and Eitan armored personnel carriers.
A tank crew today fights with the same armor and the same engine it had a decade ago, but the software running its sensors, its displays and its threat-detection logic can be rewritten in a single update cycle. That gap, between a hardware lifespan measured in decades and a threat environment that shifts in months, is the problem one of Israel’s key armored-vehicle systems suppliers says it was built to solve.
IMCO Industries Ltd. is a nearly five-decade-old Israeli defense contractor that supplies electrical systems, mission computers, smart displays and electro-optic sub-systems for the Israel Defense Forces’ armored fleet, including the Merkava main battle tank and the Namer and Eitan armored personnel carriers. The company is a designated key supplier to the Israeli Ministry of Defense’s Armored Vehicles Directorate (MANTAK), and in recent years has pushed a concept it calls the “Software-Defined Armored Vehicle”. The pitch has gained new weight following the company’s most recent contract with the Israeli MOD – announced amid a drone and loitering-munition threat picture reshaped by the wars in Ukraine and Gaza, and at a moment when armies across NATO and the Middle East are re-examining how quickly their armored fleets can absorb new countermeasures.
The Defence Blog put a series of questions to IMCO covering how it defines “software-defined” architecture in practical terms, what problem the Israeli MOD contract is meant to solve, how the company manages crew cognitive load inside increasingly sensor-dense vehicles, which of its technologies are genuinely fielded versus still in development, and what lessons recent conflicts have exposed in traditional, hardware-locked platforms.
The following responses were submitted in writing by IMCO, via its PR representative, in response to questions from The Defence Blog.
Q: IMCO describes its concept as a “Software-Defined Armored Vehicle.” How do you define that term in practical military terms, and what distinguishes it from simply adding more digital systems to an armored platform?
A: A software-defined armored vehicle is built around a common digital architecture, allowing new capabilities to be added through software instead of installing new hardware.
In a conventionally digitized vehicle, each new sensor or system is equipped with its own processor, display and cabling, integration is a hardware project which might take months, even years.
In a software-defined architecture, the hardware baseline stays fixed. The platform exposes standardized interfaces, allowing new software defined capabilities such as EW, sensor-fusion algorithms and counter-UAS functions to be deployed via software updates, without rewiring the vehicle or replacing hardware, within operationally relevant timelines.
The practical military difference is adaptation speed: the vehicle can change as fast as the threat does. But there is a second, less glamorous benefit that matters just as much over a platform’s 30-to-40-year life: cost. A stable hardware baseline means fewer configurations to maintain, fewer spare-part lines, less depot-level rework with every upgrade, and shorter out-of-service time for the fleet. Armies pay for capability twice. During the integration phase and again through decades of sustainment, a software-defined architecture cuts both bills.
Q: Your recent contract with the Israeli Ministry of Defense appears to reflect growing demand for digital vehicle architecture. What specific operational problem is the Ministry trying to solve with this capability, and how does IMCO’s system address it? Can you share the scope of the contract, or explain why those details remain undisclosed?
A: Of course, the details of any contract with any customer cannot be discussed and shared, however, it is well known that the Israeli MOD Armored Vehicles Directorate is a key customer of IMCO and thus IMCO is a key supplier to all its advanced platfroms.
The main challenge in recent years is the capability to quickly integrate new systems and sensors, e.g counter-UAS measures, active defense solutions, etc while minimizing operational downtime and allowing quick software updates. Our solution provides the common computing, networking and display backbone that enables those capabilities to be integrated and updated largely through software.
In terms of scope and financial value – IMCO is a public traded company and cannot disclose further than what is publicly published in TLV Stock Exchange market, Symbol: IMCO.
Q: Modern armored vehicles carry sensors, radios, battle management systems, cameras, EW suites, and crew displays. How does IMCO help crews manage that information flow without increasing cognitive load inside the vehicle? Has this reduction in cognitive load been validated by independent (non-internal) testing, and is that data available?
A: The key is not reducing the amount of information available to the crew but making the software smart enough to present only what matters, when it matters. The more intelligent the application and the more intuitive the user interface, the less mental effort is required from the operator to interpret raw data and decide on the next action.
For example, if a subsystem reports a fault, the crew should not have to diagnose it themselves. Instead, the software can analyse the fault, identify the likely cause, prioritize its severity, and guide the operator through the recommended corrective action. That significantly reduces cognitive load.
The same principle applies to situational awareness. A 360-degree vision system powered by AI should do more than indicate that “something is there.” It should classify the object—whether it is a drone, a vehicle, or dismounted personnel—assess its relevance, and present the information in a clear, prioritized way. The crew spends less time interpreting sensor data and more time making tactical decisions.
IMCO’s software-defined architecture enables this kind of intelligent human-machine interface by integrating information from multiple onboard systems into a unified, intuitive operational picture, rather than forcing the crew to interpret multiple independent displays.
Q: IMCO references AI-driven systems, HUMS technologies, smart displays, mission computing, and platform-wide integration. Which of these are already fielded and combat-proven, and which are still in development for next-generation platforms? If specifics are sensitive, could you describe maturity levels (e.g., TRL) without naming specific vehicle types or units? Separately – when IMCO uses the term “combat-proven,” does that mean actual use in a real conflict, or validation under combat-representative test conditions?
A: We’re happy to be specific here, because we think the industry blurs this line too often. Our smart displays, mission computers, video and data distribution systems, and platform integration solutions have been installed on operational armored platforms for many years. These are mature, fielded systems at the high end of the Technology Readiness Level scale.
IMCO keeps investing a significant amount every year on R&D to further update its solutions and adopt to the most advanced requirements.
On ‘combat-proven’: when we use the term, we mean systems installed on platforms that have been used operationally.
Q: Armored maneuver warfare is being reshaped by drones, loitering munitions, electronic warfare, and compressed sensor-to-shooter cycles. What lessons from recent conflicts – including Ukraine and Gaza – are driving demand for software-defined armored platforms, and what gaps remain unsolved? Can you point to a specific real-world case where a traditional, non-software-defined architecture failed to adapt quickly enough to an emerging threat?
A: One of the clearest examples is the rapid emergence of drones as a primary battlefield threat. Counter-UAS capabilities have evolved so quickly that armored platforms must be able to integrate new sensors, effectors, and software in very short development cycles.
On a software-defined platform built around an open digital architecture, such as IMCO’s, adding a new “shooter” capability is relatively straightforward. The new system becomes another application within the existing mission environment. Its controls and visualization appear as another page on the vehicle’s smart display, while it can immediately leverage data from the sensors already installed on the platform—electro-optical systems, radar, navigation, battle management, and other onboard sources. The crew operates everything through a unified interface rather than learning and managing another standalone system.
By contrast, on a traditional platform with a closed architecture, integrating a new capability often means installing an entirely separate subsystem, complete with its own computer, display, wiring, software, and in many cases its own sensors.