Getting a bead on the bad guys: COTS-based soft information fusion merges military C4ISR data with web and other sources

A military analyst or command and control operator could soon get much better INTEL by combining military data with information from the web.

Bottom Line: I’m unaware of anyone else yet offering a COTS sensor fusion product that combines hard and soft information sources to take advantage of Internet intelligence.

[Update 4:45pm PDT 19Mar13: corrections from "data" to information; added explanation on API and MSCT output; corrected GMTI from plots to tracks.]

Cope Tiger 13

(Courtesy: US Air Force.)

Picture this scenario: a BDU khaki-uniformed DoD analyst is staring at multiple screens of intelligence (INTEL) data and images pertaining to an unmarked ship off the coast of some unnamed country. The ship’s actions have been odd, and the Coast Guard had been tracking it for some time until it went into international waters. New satellite images now show the ship at anchor in a different location than yesterday. What’s it doing there? Are the ship’s intentions nefarious? Who is aboard, and what cargo is aboard?

This kind of scenario vexes joint military forces, Homeland Security, and myriad three-letter agencies.

The challenge for any analyst is to make decisions based upon actionable intelligence by combining every scrap of information into a situational awareness picture that maximizes what the human does best: make a decision or recommendation.  The problem with data for DoD and CIA analysts is there’s either not enough of it, or there’s too much. It’s hard to make a decision with limited information; and it’s too time consuming to dedicate an analyst’s time to culling through SAR images, GMTI (ground moving target indicator) tracks, satellite photos, transcribed radio chatter, action reports, and so on.

As well, decisions are made using more than mere “data”. Sophisticated or low-level sensor outputs are “data” (such as L0/L1 trackers), but other non-traditional asymmetric information not currently in a structured data set might also be relevant and useful to an analyst’s task.

Larus Technologies aims to change all of that with the announcement of their high level information fusion engine (HLIFE) that melds a “collection of commercially available embedded software modules for C4ISR and Security systems” into an information fusion model. Based on the company’s patent-pending adaptive behavioral learning and predictive modeling algorithms, multiple sensing modalities can now be combined together to provide a more complete C4ISR and INTEL picture for analysts.

Larus Technologies' COTS sensor fusion product uses proprietary algorithms to fuse hard military data with soft, unstructured data like web pages or civilian data bases.

Larus Technologies’ COTS sensor fusion product uses proprietary algorithms to fuse hard military data with soft, unstructured data like web pages or civilian data bases.

But the company’s product is not just one Big Data MUX.  Instead, it intelligently combines a mixture of DoD, government and other “hard” and structured data sources with “soft” unstructured sources such as weather reports, search and rescue operator reports, human intelligence (HUMINT), flight schedules, web sites, and myriad other web-based information.

The company’s Total::Insight product is a commercial solution that can immediately leverage high level information fusion and computation intelligence based upon the DoD’s Joint Director of Labs (JDL) data fusion Model. The software performs behavior analysis through predictive modeling, and is “capable of dealing with heterogeneous (multi-source, multi-sensor) data.” The HLIF engine fuses: anomaly detection, trajectory prediction, intent assessment, threat assessment, adaptive learning (situational and procedural). Details on these algorithm components can be found in their white paper “Total Maritime Domain Awareness“, which requires registraion.

This company is new to me, but the concept of offloading an operator/analyst by providing more upstream intelligence is not. Raytheon’s multi-source correlator tracker (MSCT) does something similar with military data sources such as tactical sensors. In contrast, Larus says that they are a neutral COTS vendor that can take output from products like MSCT as well as provide an API so customers can “direct the output (i.e. alerts, warnings, suggested actions) out to their favorite command and control systems.”

Still, I’m unaware of anyone yet offering a COTS product that combines hard and soft data–rather, information–sources to take advantage of Internet-based intelligence. I’ll be watching Larus Technologies; you should too.

Confused about all the different PC/104 and SUMIT-ISM specs? Then read this.

This is a short story of how ISA split apart the PC/104 industry. Here, all the hyperbole is distilled into a “Read this” primer that sorts out the various embedded board form factors.

I’ve written about the embedded boards industry for decades. At one point I even did some consulting for the PC/104 Consortium by recommending a focus on rugged and long-life applications and systems. But I can’t say I’m thoroughly familiar with all of the PC/104 specifications. There are just too darned many variations; who can keep them all straight?

Rest easy. Herein is a quick-and-dirty primer on all the specs, and how they compare. I’ve compiled this info courtesy of the PC/104 Consortium, the SFF-SIG, and friends from companies like WinSystems and Kontron.

PC/104 Consortium’s Specifications

I’m going to focus exclusively on PC/104-sized boards and ignore the related flavors like EPIC and EBX, but here’s how they look size-wise, compared to the original 90 x 96 mm (3.6 x 3.8 in) PC/104 board on the left:

A comparison of PC/104 board size to EPIC and EBX embedded boards.

A comparison of PC/104 board size to EPIC and EBX embedded boards.

PC/104 exclusively uses the ISA bus for stack-up and stack-down, whereas the other versions add or subtract PCI and PCI Express busses:

On a PC/104 board there are low-speed connections, all the way up to ISA, PCI, and PCI Express. This shows how the PC/104 Consortium's line up adds I/O and stacks.

On a PC/104 board there are low-speed connections, all the way up to ISA, PCI, and PCI Express. This shows how the PC/104 Consortium’s line up adds I/O and stacks.

In February 2013, the PC/104 Consortium ratified and made public the PC/104-Express and PCIe/104 versions shown on the right. PCIe/104 is their board-of-the-future and comes in Type 1 and Type 2 versions, depending upon the peripherals and feature set needed in the system. The brand new PCIe/104 has provisions to support PCI Express Gen 2 and Gen 3. The primary differences are shown in green. Type 2 would be used for the highest speed peripherals such as USB 3.0 or SATA; however, connector pin limitations forced PCIe x16 onto Type 1 instead of Type 2:

The new PCIe/104 comes in Type 1 and Type 2 versions, depending upon I/O requirements.

The new PCIe/104 comes in Type 1 and Type 2 versions, depending upon I/O requirements.

Note that the legacy ISA bus, and eventually the PCI bus (in PCIe/104) are dropped as the industry moves to PCI Express. These older ISA and PCI busses are supported by adding bridge cards to the middle of a PC104xxx stack as shown:

Adding ISA or PCI to the newer PC/104 stacks requires a bridge module in the sandwich.

Adding ISA or PCI to the newer PC/104 stacks requires a bridge module in the sandwich.

More information on stack-ups and how the PCI Express bus gets “lane shifted” as the stack grows can be found in the specifications for PCI/104-Express and PCIe/104.

Small-Form Factor SIG’s Specifications (SFF-SIG)

The industry fragmented over how to support the legacy ISA bus, and vendors that believed ISA I/O boards would remain popular for many years formed the SFF-SIG around 2008. Their PC/104-sized board is the same 90 x 96 mm (3.6 x 3.8 in) size but is called “Industry Standard Module” (ISM) to avoid copyright and trademark infringement issues. Instead, their specifications define Standard Unified Modular Interconnect Technology ISM boards (SUMIT-ISM) and the specification can be found here. An example of a larger EBX baseboard with SUMIT and PC/104 ISA connectors is shown below:

Caption: This is an EBX-sized baseboard that allows a SUMIT-ISM card to be stacked on it. The SUMIT-AB connectors are in the middle and the legacy PC/104 ISA bus connector is along the top edge. (Courtesy: WinSystems and TechBriefs.com .)

This is an EBX-sized baseboard that allows a SUMIT-ISM card to be stacked on it. The SUMIT-AB connectors are in the middle and the legacy PC/104 ISA bus connector is along the top edge. (Courtesy: WinSystems and TechBriefs.com .)

As for connectors and I/O on SUMIT-ISM boards, it uses the same Samtec Q2 double row, high speed 15.24 mm Q-strip connector system as does the PC/104 Consortium. The following table compares many of the common SUMIT-ISM I/O types (Column 1) to the PC/104 Consortium’s flavors, including the new Type 1 and Type 2 PCIe/104 just announced:

How PCI Express is implemented on SUMIT-ISM board and PCIe104 boards Type 1 and Type 2.

How PCI Express is implemented on SUMIT-ISM board and PCIe104 boards Type 1 and Type 2.

For additional explanation of how the ISA bus split the industry, read WinSystems’ article at TechBriefs.com .

Conclusions

It all comes down to a philosophical choice. If your design needs ISA and newer, contemporary processors, your choices are the original versions of PC/104 and SUMIT-ISM. When your system starts needing variations of PCI and PCI Express, you’ll need to examine how best to implement those busses in the stack-up: with or without bridge modules.  If you just want PCIe, then both SUMIT-ISM and the new PCIe/104 modules have you covered.

 

HTML5 Is What’s Needed To Rapidly Develop IVI Automotive Apps

HTML5 logo

Car manufacturers know that in-car technology like navigation systems sells cars. The pace of the smartphone movement is impacting the painfully slow speed with which automotive manufacturers develop new cars and tech features. Consumers trade out their phones every 2 years, but a two year old car is still considered nearly “new” by Kelly Blue Book. So how can the auto OEMs satisfy consumers’ tastes for updated, red-hot in-vehicle infotainment (IVI) systems and add-on Apps?

Elektrobit speaks about HTML5, IVI, and HMI for automotive markets

Automotive software supplier Elektrobit thinks HTML5 is the answer. Coincidentally, so does RIM’s QNX division, along with Intel.  QNX supplies “CAR 2″ software to several auto OEMs, and Intel is behind Tizen, an HTML5-based competitor to Android.  While Samsung has endorsed Tizen for a handful of smartphones, Intel has publicly stated that Tizen is also targeting automotive IVI systems as I wrote about here.

At a webinar today (5 March 2013) hosted by Automotive World magazine, Elektrobit’s VP of Automotive Rainer Holve, argued that HTML5 is the perfect language in which to develop and deploy the fast-changing IVI HMI software. Most importantly, the car’s core “native” IVI functions should stay separate and subject to safety-critical coding practices.

By partitioning the IVI software in this manner, the two ecosystems are decoupled and can run on their own market- and OEM-driven schedules.  This means that native IVI–like GPS navigation, audio, HVAC, or OBDII diagnostic information like fuel consumption–can be developed slowly and methodically on the typical 2-5+ year automobile OEM cycle.

But the faster moving, consumer smartphone inspired IVI portion, and its fast moving add-on Apps ecosystem, can move very, very quickly. This allows consumers to refresh not only the Apps, but alows the OEMs to upgrade the entire HMI experience every few years without having to replace the whole car.

HTML5 decouples the slow automotive dev cycle, from the super-fast IVI App cycle.

HTML5 decouples the slow automotive dev cycle, from the super-fast IVI App cycle.

While the OEMs would love for an HMI refresh to force the consumer to replace the car every two years, it’s not going to happen. HMTL5 is a reasonable alternative and they know it. According to Elektrobit, Chrysler, GM, and Jaguar/Land Rover (JLR) have already started projects with HTML5.

HTML5 is an “evolution and cleanup of previous HTML standards,” said Elektrobit’s Holve, and is composed of HTML+CSS+JavaScript, along with new features for A/V, 2D graphics canvas, a 3D API, support for hardware acceleration, and much more.  HTML5 is based upon open standards and is supported by Web Hypertext Application Technology Working Group (WHATWG) and the World Wide Web Consortium (W3C). Independently, W3C is working on a standardized API for JavaScript, which makes the HTML5 value proposition even sweeter.

Besides decoupling the HMI software from the “core” HMI functions, HTML5 would allow third-party Apps developers to swiftly write and deploy applications for IVI systems. Besides Internet connectivity itself, this is the one IVI feature that consumers demand: a choice of what Apps to add whenever they so choose. And since every automobile OEM will have to certify an App for safe in-vehicle use with their particular system, HTML5 allows App developers to create one core App that can be easily modified for multiple manufacturers and their myriad (and differentiated) vehicle models.  In short: HTML5 makes things easier for everyone, yet still allows a robust third-party market to flourish.

It’s important to note how this is both similar to, and differs from, the current IVI strategy of many OEMs that rely solely on the smartphone for Apps. Chevrolet, Peugeot, Renault, Toyota and v others tether the smartphone to the IVI system and “mirror” the phone’s Apps on the screen (see my blog on Mirroring). This allows the wildly robust iOS and Android App ecosystems into the car (and soon RIM/Blackberry and Windows 8 Phone), but it comes at a price.

2013 Chevrolet MyLink IVI uses MirrorLink with smartphone apps

2013 Chevrolet MyLink IVI uses MirrorLink with smartphone apps

In this scenario, the auto OEM must certify every App individually for use in their vehicle to assure safety or that critical car systems can’t be hacked or compromised. Or, the OEM can allow all Apps to run and hope for the best. One hopes a rogue App doesn’t access the CAN bus and apply the ABS or electric steering.

HTML5, on the other hand, gently forces developers to create Apps destined for IVI systems, but adds only a slight burden on them to make minor changes for each manufacturer’s certification. In this way they’re not barred from the car indiscriminately, but can develop a business of IVI apps separate from their smartphone iOS, Android and other Apps.

Intel's Renee James is betting on HTML5 in Tizen to kickstart transparent computing. (Image taken by author at IDF 2012.)

Intel’s Renee James is betting on HTML5 in Tizen to kickstart transparent computing. (Image taken by author at IDF 2012.)

Will HTML5 be successful? Is it the right answer for the rabid consumer’s taste for car tech, while still giving the auto manufacturer the safety and security they’re required to offer by law? I was skeptical about Tizen until Samsung’s announcements at Mobile World Congress 2013 last month. With Tizen pushing HTML5 for “openness”, it may just gain traction in automotive, too.

Watch this space. We’ll keep you updated.

SMARC: ARM’d for a Power Play

ARM is migrating into the embedded board market, at the expense of x86 designs.

ARM is migrating into the embedded board market, at the expense of x86 designs.

In the world of multicore, it’s hard to get more cores than the quads now shipping in the latest smartphones, most of which are based upon ARM. But what about the board-level embedded market that I follow more closely?

You know it’s a foregone conclusion that ARM’s going to win the low power wars here too when even the x86 PC/104 vendors start musing about the need for ARM roadmaps.

 

WinSystems VP Bob Burckle spins a PC/104 board. The company is considering adding ARM processors to its predominantly x86-based boards.

WinSystems VP Bob Burckle spins a PC/104 board. The company is considering adding ARM processors to its predominantly x86-based boards.

In my discussion with WinSystems–a company that helps drive usually Intel-focused x86 trade consortia–Bob Burckle ponders an open standard form factor for ARM-based single board computers.  .

I’ve come to learn that ADLINK, Congatec, Kontron and others have pushed the very concept of ARM-based SBCs through the Standardization Group for Embedded Technologies (SGET) in a computer-on-module (COM) standard they’re calling Smart Mobility ARChitecture SMARC version 1.0.

Smart Mobility Architecture (SMARC) is a COM processor module ideally suited for ARM processors.

Smart Mobility Architecture (SMARC) is a COM processor module ideally suited for ARM processors. (Courtesy: Standardization Group for Embedded Technologies, SGET.org.)

It comes in 82mm x 50mm and 82mm x 80mm flavors, and Kontron is already implementing it for aircraft passenger In-Flight Entertainment systems.Figure 2 Kontron IFE plane cut-away

Look for ARM processors on PC/104, VME, COM Express…and SMARC boards soon. Choices will be from Texas Instruments, Atmel, Qualcomm, NVIDIA, Xilinx, and even AMD (which licensed the ARM for security engines in its APUs).

Kontron SMARC-sAT30 is a low profile platform based SMARC specification and integrates the 1.2 GHz NVIDIA Tegra 3 quad-core ARM processor (Cortex A9).

Kontron SMARC-sAT30 is a low profile platform based SMARC specification and integrates the 1.2 GHz NVIDIA Tegra 3 quad-core ARM processor (Cortex A9).