COTS and portable equipment challenge mil/aero suppliers
CONDUCTED AND MODERATED
BY PAUL O’SHEA
Electronics Products is pleased to convene a noteworthy group of experts to talk about some challenging topics affecting the suppliers of the mil/aero marketplace. Military aerospace suppliers face special challenges to provide excellence in design, pushing the limits of security while meeting the exceptionally rigorous environmental requirements and at an industry-competitive price.
Electronic Products: To start this off today I’d like to ask each of you about trends. What trends do you see in the mil/aero industry?
Dane DeLozier (National Sales Manager, Calex Manufacturing) : It’s been an interesting time. We at Calex haven’t traditionally participated in a military or an avionics industry as a main focus of our sales. The military and avionics industries are finally moving toward COTS products.
They have talked about it for many years, but they are finally implementing commercial grade parts. This opens many questions, questions like (1) in what types of applications are they suitable, (2) what reliability data is going to be required, and (3) how are we going to manage the perceived risks of RoHS? It is very clear that the world has not reconciled answers for these questions, and we see almost a negotiation go on as we are invited to participate in various programs.
Everybody has a very different take on what ought to be accepted. And I don’t know yet if the military has even clearly stated anything about applications. The opinions even among the big contract players of that industry, such as Lockheed, Northrup, Raytheon, and others differ greatly.
For example, in the applications where COTS are used there seems to be a delineation of how much safety must be built in. Generally, if it is flight-critical, it is not acceptable. However, there are times when we feel that the applications are getting closer and closer to that line of acceptability.
Regarding what reliability data is going to be used, Mil Handbook 217F is often the guiding standard of calculating MTBF. That said, the calculations required to provide a good number to our customer is challenging, not because we are incapable of providing it, but because we have many commercial legacy parts that the military wants to use. It becomes very time consuming conducting the evaluation.
So, our customers are using field data, statistical information on the history of returns, and Belcore calculations to arrive at some suitable understanding of MTBF. And finally, regarding RoHS, the military has no choice but to accept RoHS-compliant parts, and they truly do not know the long-term reliability of these parts. They use tools like the Pinsky analysis [an algorithm] to predict what will be the weakest link or the highest-risk component in a circuit.
Our response has been to listen closely, conduct our own evaluations, work with third-party labs, and follow the leaders among the big defense contractors today.
Ralph Wise (Director of Technology, Ultralife Batteries) : We’re seeing a drive for lower-cost solutions. We’re seeing a higher energy and higher power dense technologies specifically to support longer and more remote missions also the optimization of logistical expenses certainly.
So anything that our products can do to optimize those are certainly being welcomed by our military customers.
Ross Smith (President, Quantum3D) : I think the notion about lower cost is the key requirement in the market, and this is not a new trend. For those of us that are in the COTS market, cost is always the key factor.
We’re also seeing that a lot of our customers have started to really come to grips with the cost of COTS obsolescence issues. For the first time we are actually seeing procurements by customers that are contemplating technology insertion where they realize that they may have to buy lots of end-of-life components and parts, which doesn’t really make sense in a COTS world.
Now they’re starting to really think about how they can incorporate this notion of technology insertion in their architectures so they can benefit from change as opposed to resisting it. And I think that technology insertion will have long-term positive benefits for the military assuming that they really contemplate technology insertion on a broad scale for both industry-wide and service-wide as opposed to on-point programs, so that the benefits of the tech insertion may be spread across multiple programs.
Rodger Hosking (Vice President/co-founder Pentek) : What we’re seeing is people looking for higher levels of integration from COTS venders that — what used to be, for example, just a board, now they would want a board perhaps with some subsystem function like a recording subsystem all ready to go so that when they buy the board set or subsystem, they don’t have to do as much development.
This is all towards reducing risk and ultimate lower uncertainty and so when the solutions actually are going to be deployable.
We’re also seeing some rather unique and extensive environmental requirements coming down that tend to be different for each application and each customer.
And trying to address each one of those requirements separately is sometimes a large part of negotiating a particular opportunity.
Gordon Hunt (Chief Applications Engineer, Real Time Innovations RTI) : RTI provides middleware software infrastructure so we get involved in a lot of different integration efforts. And what we see is a real push for open systems.
Everybody wants these things to be able to interconnect with everything else with full interoperability, and I think a lot of people get the words interoperability and interchangeability kind of confused. What people really want is to build once, use many.
Say they want to design a system or a sensor and they really don’t know exactly who’s going to use the output from, for example, an acoustic sensor, although they know that many different people are going to want to use it and they really want to make it so that five, even 10 years down the road the acoustic sensor is still relevant and can still be accessed and leveraged by a bunch of different technologies or systems they didn’t even know about when they designed the system.
And that goes with what we’ve been seeing in that the requirements in technology are really outstripping the whole government acquisition timeline.
SPAWAR has a two-year rapid acquisition cycle, but efforts are actually sometimes not rapid enough. Often COTS technology is out of date even before you’re even done with the contracts phase.
We also see a strong really big push on networking. I think a lot of distributed systems that initially were deployed on a rack of one or just a few computers with some often-proprietary hardware integrating them altogether are going towards widely distributed systems.
Now this doesn’t necessarily mean wireless networks, although we see that as well, but rather than have several high-performance dedicated hardware machines would go to many, many, many standard COTS pieces of hardware on standard networking infrastructure.
This leaves interesting challenges in system integration and software management when you start going from just a few applications to maybe tens or even hundreds of applications now that we have to integrate and maintain stateful behavior.
Where we come in is we see most of our customers really have embraced the COTS hardware. They’ve embraced COTS operating systems, and they’re in the process of embracing COTS middleware.
And I would agree with the earlier comments that they want these things to be fully integrated kind of at the get-go.
Ben Helminen (New Programs Manager, Saft Batteries): Saft is an energy solution provider for portable military equipment and in that area we definitely see an increase of portable systems needing power sources used by our military.
We see the need of multiple technologies because of the large variety of needs for different applications.
We also see that more and more features within new equipment are resulting in a need for higher-energy or higher-power solutions.
We see a trend towards power sources that are smarter and, of course, lighter and smaller.
And also a trend for soldier systems with a centralized power source, for example, for soldier modernization programs where basically one power source is supplying energy to several applications carried by the soldier.
Electronic Products : Ben, what kind of multiple technologies were you referring to when you were talking about the power sources?
Ben Helminen : With batteries there are different technologies suitable for different requirements. So, definitely multiple technologies are needed to meet the requirements of different applications. Saft has a variety of technologies to be in position to offer solutions for different applications.
Jeff VanZwol (Marketing Director, Micro Power Electronics) : I’m going to reiterate what some of the other speakers mentioned. What we’ve seen, just from an economic perspective, is that for some of these military programs the customer, ultimately the military and OEM customer, will take what is typically a custom set of requirements and break them up into custom piece and then segment certain pieces to use as COTS products.
For example, I’ll use a custom charger where the external power supply is an off-the-shelf power supply that can be sourced globally.
So we see the ultimate customer being very aggressive on hitting almost near commercial price points for some of the products that they’re putting out RFPs.
From our perspective we build custom portable power solutions and chargers and one of the main trends that’s driving our military business is just the continuation of deployment of the Land Warrior program and this is a program where the military is outfitting the infantry soldiers with lots of different handheld and wearable-type devices like radios and night vision goggles, helmet-mounted displays, devices like that where there’s a high need for portable power.
Bill Standen (Vice President Marketing and Sales, Martek Power) : The two trends that have been ongoing is really power density and price. Those are the two key factors with, of course, price being very important.
Power density and smaller size are important because the size of an F16 hasn’t changed greatly since the ‘80s and you have to put more into the same space.
With respect to newer trends we’ve seen, I think someone mentioned RoHS. That’s been a real interesting situation because we see certain customers, certain prime contractors, are going in one direction while other contractors are going in a different direction.
And if you’re supplying to the European market, they’re going in all directions. Some say we have to have RoHS, and some say we don’t.
I think in the U.S. it tends to be a more uniform message of we have to be careful, we have to mitigate tin whiskering and things like that. So I think in that sense it’s been a little easier there.
Another I think important trend we’ve seen — and this is more in the system level not the component level because we provide both but we’re seeing more of a need for certain universal inputs meaning wherever that piece of equipment is deployed, customers really aren’t sure what base power they’re going to be dealing with so the systems that they’re looking at should be capable everything from, three-phase ac down to 28 V and everything else in between.
And I guess lastly, the point of obsolescence, we’ve been sort of providing off-the-shelf products now really since the ‘60s so we’ve always had a mantra of form, fit, and function, we’ll guarantee.
And at times there are customers who will accept that and there are times where customers will say, “No, I want to be able to drill down to the component level.”
I think more and more we’re seeing that form, fit, and function are sort of becoming more accepted as the military wrestles with the obsolescence issues.
Electronic Products : Portable equipment has become a standard in military gear, but a high rate of charge/ discharge adds new electric and mechanical challenges to traditional charger designs. What factors affect the selection operation of portable military devices?
Jeff VanZwol : I think what this question is referring to is that in the last year or two, we have seen the recent introduction of high-power cells for commercial applications.These cells typically would come from vendors like A123 and E-One Moli. They’ve been recent introductions into the battery industry.
When we talk about what the criteria is for where cells go in the portable devices, I think there are a couple of things that you have to consider for a portable device.
One is price sensitivity of the device. These cells are typically a higher price than the traditional cobalt oxide. Also is there a need for a cell that can support a 10 to 100-A pulse or can you get away with a traditional oxide cell.
Other considerations: if you do select a cell to put into a portable device, you will typically have to look at a custom safety circuit because commercial safety circuits that are needed with these cells are not typically available as off the shelf.
Ultimately what you’re looking at when you’re considering these cells for a portable device is a higher per-unit-cost as well as some higher non-recurring expenses (NREs) to get that battery pack integrated with the device.
If you look at the charger side, you have to look at how fast the charger must charge the cell.
A charger will typically charge a standard battery pack in about two to three hours, but with these new cells you can have them charge as fast as 15 minutes.
And the implications of that are you’re charging a cell within 15 minutes. Then you need to know what the size of the power supply is as well as how do you dissipate heat in a battery charger that’s charging at that high of a rate.
Ralph Wise : From a much wider viewpoint, one of the points about high charging is specifically how long the military mission will be. Specifically, one of the things that you work out very quickly on paper is that high-power batteries are very good in very short mission times, which do exist out there.
We’ve seen the market segment itself with regard to specific applications based on user scenarios. And customers have come to us and asked us if we can build batteries with higher power, but the energy isn’t necessarily needed.
And Jeff brings up a good point which is the thermal management of the batteries, specifically with the Li-ion chemistries, and even if you’re using some of the more exotic chemistries available.
We have noted that we need to make battery packs as safe as possible so I want to underscore that as well. I’m sure that, they’re seeing the same types of issues we are. These cells that were created for the power tool industry also have other challenges, which raise their development price.
Ben Helminen : I would like to join in with what Jeff and Ralph said and add that I think that the application can be the same, but it’s really very seldom that there’s one design that fits all operational situations because within the Army there are customers using the equipment in very different modes and that can lead to some very customized solutions.
I think there are also questions concerning the use of primary power sources versus rechargeable power sources. I think that one of the selection criteria is the operational use of the batteries. For example, the mission’s requirements, the length of the mission, and of course the unit cost and life cycle cost for the product.
It is also important, when selecting a power source, that there be an industrial base to support the manufacturing of those devices.
Ross Smith : One of the things that we see has to do with what appears to be a lack of a system-level design approach where we see a number of either primes or primes plus government labs collaborating on a project or they want to bolt together software and hardware from a number of different vendors to try and achieve some kind of objective.
We see they may be using software from an application environment that uses big desktop or rackmount computers, but now they’re going to try to use it in a deployed environment such as a mobile system.
There’s a huge mismatch between the software requirements and what you can actually deploy in the portable or mobile system, especially for wearable applications, and it makes for some interesting bed fellows where you have people that have 400- or 500-W desktop systems that are required to run the software and they want to put this on a 30-W mobile system.
I think that there will have to be a higher level of contemplation about matching hardware to software requirements to try and deploy very advanced applications in the field. They are not thinking about the kinds of power systems and the kinds of compute power that they have in the field.
Electronic Products : What could the government do to encourage greater use of COTS technologies and products to improve deployment timeframes and reduce costs?
Ross Smith : We see a lot of situations where the government desires COTS technologies, but they oftentimes levy a whole set of MIL standards that would go along with the traditional, complete acquisition program onto the COTS technologies.
To some degree you can modify COTS technologies to meet those requirements, but you also end up defeating a lot of the real benefits of COTS technology in terms of price and deployment.
Where the government can really benefit from COTS technologies would be to make better use of market surveys in the acquisition process to really understand where COTS technology fits and where it doesn’t fit, and where modification of COTS technologies can really benefit them.
We see a lot of situations where customers want the price advantage and the fast time frames of COTS technologies, but they want all of the life cycle support that goes along with full MIL-spec procurement.
I don’t think the government really understands how they should be sourcing the appropriate technologies for different programs.
Dane DeLozier : We’re seeing the same thing. That’s the ambiguity I referenced earlier when we started. The defense contractors themselves are not clear on where, exactly when, and how they employ that.
I don’t know if it’s the government that hasn’t been clear. It’s funny how that always works. It’s sort of like they’ll throw out the statement that “we want it to be a COTS product, we want it to be a COTS price, but we want everything that we had before in our military-specified products.”
Ross Smith : What we need is a list of procedures that they want you to fill out for your COTS products.
Dane DeLozier : So ironically, we’re a commercial dc/dc converter manufacturer that customers come to. They throw a device out on the table trying to engage us, but there’s still this ambiguity about how or what is going to be actually required of that device and how much qualification will be required.
And before you know it, you can be into a product that ends up costing what a full military product cost 10 years ago and they sort of undermine themselves.
So, maybe one thing the government could do is be a lot more clear about where, when, why, and how they deploy that and under what circumstances.
We had one customer — I’m not going to mention the customer’s name, a substantially sized defense contractor — say that the delineation is going to be where it comes down to safety.
This was in a missile application and was sort of ambiguous. Does it mean human safety? What kind of safety?
It was a very nebulous statement and they ended up using a COTS product in a very risky application.
Ralph Wise : We’re building COTS products to FAA DOT54 and DO178 B level A standards — which are the safety-critical standards for commercial airliners.
You still face this — these are requirements where they want some other standard, to be conformed to and you have to test against that. And they’re really bristle when you say, that you have to charge them incrementally for this testing because you don’t really support that as part of your product.
Bill Standen : Just to add to that, I really think the ambiguity issues are very much out there. I have to agree with everyone. But I really see the ambiguity not so much in the government level, but much more on the contractor level. Particularly in the design engineering realm because I just don’t think that there’s a very good definition.
And Ross mentioned, the dc/dc converters which is an excellent point because that particular marketplace extends from, built-in-China for pennies to built-in- a-clean-room for $1,000. It’s just a huge, huge price difference.
And when you apply a term like COTS to that, it begs for ambiguity and I’ve seen a few major contractors we serve who are trying to get their arms around it. For example, one of our divisions that makes products that are typically used in a human environment. It could loosely be defined as COTS, but not something you’d really want to recommend. It’s more industrial and a customer would come to us and tell us that “We had a problem with it.” And we say, “Well, this product was built by a particular division,” and they respond: “Yes I know and I now know I should’ve used a different product, but how do we fix it?”
That’s unfortunate because we really need a better definition for certain component parts on the part of contractors. I don’t know if it’s an industry group that could do this or if we have to go back to the days of government specs coming out like NAVMAT or something like that, but a better definition is key.
Ross Smith : There are a couple of us that have tried to get this inserted into the defense appropriations bill, we’ve been able to get some of that clarified, but the problem really goes back to the Federal Acquisition Regulation Supplement (FARS) and Defense Federal Acquisition Regulation Supplement (DFARS) where commercial is defined, but there’s no real definition for merchants which is another level of commerciality.
And there’s no good definition for COTS either, although there’ve been attempts to try and litigate that. And until that’s really well defined and understood I think we’re going to face this kind of ambiguity and, that percolates from the government due to contractors and ultimate that affects all of them.
Jeff VanZwol : Based on responding to some RFPs late last year when the government sent out RFPs they have an ITAR statement right on the beginning which applies to all the RFPs.
And there are elements of the RFP that I personally believe do not affect national security. One thing they could do when they look at an RFP is to segment out the sections that they believe affect national security and identify those that don’t.
For those that don’t, we could, for example, use Asian supply chains to fulfill some of those requirements. For example, a plastic mold that goes with a charger or battery pack, you can source it in the U.S. domestically or you can source it in Asia.
Your NRE affiliated with that mold as well as the turnaround time on the molding equipment is a lot faster if it is sourced in Asia. Personally I don’t think it affects national security, but since there’s ITAR on the header of the RFP, everything has to stay domestic.
Gordon Hunt : On the software side of the fence, we see a lot of existing systems, combat systems, and radar air traffic management systems have existing infrastructure software, middleware and/or networking that’s been around for quite some time.
The systems are obviously deployed and working and then they get a mandate to move towards COTS. Then you get a pile of software and a real reluctance to change any of it.
It’s viewed as a risk. So you end up moving towards COTS with a lot of very heavy infrastructure, heavy in terms of just the software code base that doesn’t let you adopt or even properly move towards the COTS infrastructure.
For example, you might have a system that was originally built on point-to-point serial communications infrastructure and all of the communication infrastructure was hard-wired into your application code. Your application now knows, that rather than write once receive many, if it’s serial, you have to send point-to-point communications. And your application manages that.
Now when I move to COTS hardware, say an x86 Linux box, we see a lot of real time mission critical combat systems moving to Linux and hardware on Ethernet.
But they don’t really address the underlying software infrastructure problem and so you end up getting COTS hardware, getting maybe even COTS middleware, mapping all of that to the existing or the legacy software infrastructure to make the new COTS hardware and infrastructure look like the legacy stuff and then run the legacy software code base on top of this now, mapped layer.
And you do this a couple of times and you end up with a very interesting software infrastructure. I think proper software partitioning or project partitioning when you do spiral upgrades, and a really good hard critical look at what should be COTS and a realization of what that means. It means you don’t need to keep this whole layer of software or this piece of hardware that dealt with this proprietary piece of hardware. We don’t need that anymore.
Over time that leads to a much less costly system. It certainly is more scary up front. You have a whole layer of code that you’re ripping out and that means you have to retest different things so there are many questions that result when you start looking at spiral upgrades to large software code bases.
Ross Smith : I think Gordon hit on a really key point which is the lack of software architecture with the ability — and this really comes from the government — to design systems appropriately with the right software architecture because they are trying to build a lot of existing software on the new platforms and it works against everyone because now you have the — an old inefficiency of software and you’re not taking advantage of new technologies, and now you’re trying to make new hardware, solve these software problems and you end up with huge inefficiencies in this field.
We’re facing this with some of our customers. We’re having to deploy two or three times the hardware compliment that you would if you rework the software just to meet, just to deal with the inefficiencies of their legacy software and hardware requirements.
But if they rewrote it, it would be much more efficient and lower power system. I think they are afraid to do so. I think part of it has to do with the fact that maybe the government labs don’t have the right resources anymore to really take on these kinds of tasks, to really look at the requirements and understand them.
So they throw their hands up and let the primes, the big primes really go off and try and pursue these jobs for them and then the primes themselves aren’t willing to go off and invent new technologies to redo this.
Gordon Hunt : Yes, I think it’s a “what we have works so why should we change it” kind of philosophy. And I, like an algorithm that takes information from a radar and properly turns it into actual tracks, there’s a lot of IP just kind of hard won knowledge in that.
Now does that mean that the algorithm needs to change? No, the algorithm actually is probably fine, but the infrastructure that feeds that algorithm and the algorithm, whether or not it can take advantage of, parallel processing or not, and these kinds of things should be addressed.
So keep the algorithms and look at how the infrastructure is moving information around is what I usually end up telling customers.
Rodger Hosking : I’d also like to echo the idea that the tendency is for government technology decisions to be outsourced to the primes. And in a lot of cases, we’ve seen primes take over decisions that previously were made by government agency engineers. And those folks are probably now actually working for the prime contractors.
Unfortunately in those cases, decisions may be made by the primes that are self serving to the prime rather than necessarily self-serving — then serving the government in the best way.
So in one way if we could get some more of the technical innovation and decision making done at the government level as much as sometimes that doesn’t seem to work, it might tend to avoid this segmentation of different solutions that are not compatible and ultimately which costs the government more.
Ben Helminen : Looking at it from a different angle, I think that we all see that COTS is something that is recognized to be used by the government, although there is a question about the definition of COTS. However, it’s also to understand that it’s very critical to maintain a domestic industrial base that can support the government in crisis situations because the government’s need is very unpredictable, and has very big swings. If the domestic industrial base is not maintained it can lead to very significant supply issues.
Having been a supplier in several military operations, we have seen how it is critical to have a strong domestic industrial base to support the government.
Electronic Products :The VME Bus International Trade Association or VITA vendors and users have a common market interest in real time modular embedded computing systems and champions open system architectures as opposed to proprietary system architectures.
How are new VITA standards and high speed serial interfaces impacting the military-commercial market?
Rodger Hosking : We’ve definitely seen change, since about 2003, when some of the first standards in VITA were introduced, the VITA 41 which is VXS and the VITA 42 which is the XMC, the first is the switch serial fabric extension to the VMEbus and the second, the XMC, is the switch serial fabric extension to the PCI mezzanine card, or PMC module.
These tend to be building blocks for a lot of embedded military systems and having those new extensions with the switch fabrics was a major event in terms of government electronics for embedded systems.
We’ve seen most of the customers welcome this new technology and these new standards as a way for several vendors to come together and produce compatible or competing solutions that would allow the government to choose from an open standard architecture so that their perception of risk is lower and the more vendors that rally around these particular standards, the more comfortable with government customers feel.
So this standardization process has been a real blessing in terms of establishing that credibility and sometimes a rather slow moving evolution of system requirements that flow down from the customers.
The switch serial fabrics that are being used have been enabled largely by FPGA technology. Many of the new FPGA families from (Altera) and from (Xilinx) have built in gigabit serial interfaces that allow vendors – board vendors – to build boards with those parts on the boards anyway and automatically bring along with those parts the high speed gigabit serial interfaces that kind of come along for free which simply can be connected up to the pins that then go to these new standards.
I think, while that sounds quite easy and simple, the real challenge in the industry is for the infrastructure and the IP and the middleware that allows the systems to really take advantage of these high speed gigabits serial interfaces, using common software tools and methodologies, are still quite a long ways from being standardized and winds up being more of a systems integrator’s responsibility to implement his own proprietary constructs for getting the data to move the way he needs it.
But I think we’re lacking standards that we want on the protocols and software and the middleware for these new VITA standards. The hardware and the electrical interfaces are there, they’re ready to use, ready to go and starting to be deployed into government systems already.
Gordon Hunt : Just following up on the comment there about the middleware and the availability to support the VITA standards. As applications move from legacy and proprietary infrastructure, some of these systems such as sonar systems, have significant data rates and a high degree of reliability.
Companies see COTS, and they want to go the COTS route and often the first reaction is to move right on to IP, an Ethernet based or gigabit Ethernet design, and often the latency and the throughput isn’t enough and they consider that a COTS failure.
With the addition of some of these other transports and these standards, what we advocate, at a data level, you shouldn’t really care what transport you’re running on and how that information is moving.
You should pick the appropriate transport that has the delivery latency throughput performance characteristics that you need and then your applications through use of middleware should be able to send data over one or multiple different transports.
Although we haven’t seen anybody leverage this at a middleware level yet, I fully expect it to happen.
The trend is to port 5% or 10% of an existing system to our COTS framework. That tends to work pretty well. As you know, in quantities of scale when you have two, everything works. When you go to five or ten, things start getting iffy. And when you go to the full systems scale, nothing works at all.
So, what we see is that the first internal research and development (IRAD) efforts work really well for IP and then when they start scaling up, they run into the performance issues and they start looking for other COTS standards to meet their performance requirements. I see this as a highly leveraged standard going forward.
Rodger Hosking : Specifically, the fabrics that we see being used in embedded systems are PCI express for pretty much point to point connectivity and then serial RapidIO seems to be one that many of the traditional mil vendors are choosing for moving data.
To that end, it’s quite interesting that Freescale and its MPC8641 processor, which is its latest AltiVec PowerPC, a popular processor for embedded systems as both a PCI express and a serial RapidIO native interface engines that are built into the processors as a peripheral.
That indicates that Freescale thinks that these are important standards. TI is also incorporating a serial RapidIO into their latest DSP processor engines.
So I think we’re going to see those protocols be quite popular, but to the last point, when you’re trying to move data from point A to point B in a dedicated fixed path, often a very lightweight protocol or raw protocol is required, like the Xilinx Aurora or the Altera Serial Lite. These are link-layer protocols that can move data very efficiently.
The nice thing about it is that the physical interface, the electrical interface among these different standards is the same so you can choose appropriately the protocol that you need.
The downside, of course, is that you can get a system with mixed protocols that are implemented in a specific way by a specific system integrator or prime that would then tend to make it less easy for interchangeability with boards or subsystems from other vendors.
And then, of course, the software layer that drives it all can become rather complex because you’ve got these multiple protocols to deal with.
Electronic Products : The DoD is seeing continued push toward the interconnectedness of all things. How successful are the efforts and what is and isn’t working?
Gordon Hunt : This is a topic that’s near and dear to me and has been very interesting to watch over the years as people go down this path.
We all have seen and read the net centric warfare publications and white papers and, as a kind of a guiding principle everybody, I think, would agree with the objectives of net centric warfare and increasing the speed of command an making data available to those that need it.
The vision that I’ve seen from the various high level slides that are presented at different conferences show a picture of a battlefield and little lightning bolts going between everything. And that is the driving goal.
Then we get to turn around and implement all of those different lightning bolts. And I think people are really coming to understand what this all means, what data really needs to go where and how it’s going to get there.
It means mixing both wired and wireless networks and you have different protocols and link layer networks to deal with as well as application interfaces and the various data models that you have to leverage.
There have been schools of thought where we just cast everything to a string version of XML and we send it around that way but that has various limitations when you get into packet size and message size.
And then if you binary encapsulate everything on a dedicated link then just as the last question indicated, you start having interoperability and interchangeability challenges.
There is a school of thought that says we should just use the same design everywhere for net-centric or interoperability approaches. That obviously has some extreme limitations when you look at system-to-system integration and when one system was implemented by a completely different defense contractor than another because each will use different hardware and software infrastructure parts.
So you end up with a real deployment challenge with the simple “use the same parts everywhere” approach.
Then you end up with what I would classify as building bridges between all the different sub systems. This is a point to point technology integration where you take a look at the various pieces that you want to integrate and you end up building many different application layer bridges between the different systems.
This is very challenging because some systems can be very message centric in that they expect a certain application level protocol and certain kinds of handshaking to occur. Meanwhile, another system is very database centric and it’s a pulled data model, where you pull the data that you want and you don’t really worry yourself about all of the handshaking protocols.
When you want to integrate these two systems together you end up with a real logistical nightmare and have to build some very specialized interfaces that understand the protocols on both sides. This runs into some real scalability and deployment challenges down the road.
The third approach which I see gaining traction is a focus on the data and not the technologies. The technologies, as we see with COTS are rapidly coming and if you pick a technology you end up trying to use that first approach, which is using the same design everywhere. So service oriented architecture, although it’s easy, it doesn’t solve the problem.
What I see that’s working is people stepping back from the actual infrastructure, the hardware, the networking and the transports and even the middleware and saying, “Okay, what information do we have? What data do we have? Let’s make that common,” and then I end up building bridges between different interfaces. It’s like a build once, use many kind of interface. It’s a middleware to a database. Build that once, it’s the same data in both the middleware and the database so I don’t care what approach you employ to use it.
I think the standard certainly is working. It definitely raises awareness throughout DoD and government on how to approach interconnectedness and interoperability between everything, although it isn’t a panacea. However, because you have standards, doesn’t mean that it’s going to work at the end of the day. So I can use a standard, both hardware and software, and still package my data in proprietary binary formats.
So, I think the government and the acquisition project managers and the various program leads really need to take a look at how people are building open systems, how the various sub system elements are defining the data.
For example, if you take a look at a ship, you have the ship gyro that has information that many different systems need, including ship position, ship roll, and pitch so that you might fire the guns or aim various parts of the radar, or whatever.
So rather than building point to point connections between that ship gyro and every other system on the ship, why not take a look at the data coming out of that gyro, capture that in a standard format and then anybody out there that needs that data can access that information through an appropriate technology bridge. It’s very clean and very scalable.
Dane DeLozier : We see it from more of the hardware side of the equation and really it is an interesting observation for us. The defense contractors are definitely doing better. I agree with what you were saying, Gordon.
Over the last five or ten years there’ve been a lot of acquisitions. They’re only now beginning to integrate all those divisions and acquisitions into, more integrated systems approach to their products.
But where we come into play, it hasn’t worked yet so well. That is the point of use. Whether it’s a legacy system that they’re trying to build onto, whether it’s an entirely new installation that needs to interface with other systems, whether it’s on a Humvee, it’s a mobile satellite, it’s aboard a ship or on a plane, there are all these sorts of mechanical or electro mechanical challenges that they have.
From the software or networking perspective there seems to be an early engagement. We get pulled in late into the equation and we’ll end up providing what comes to be a very complex converter that has to fit into a very challenging electro-mechanical configuration.
And it ends up being quite an investment of time to development. Had they standardized or formalized what was needed earlier, it may have been made much easier for everyone.
Jeff VanZwol : I’ll just throw in a different view with respect to inter-connectiveness and it ties back to what we talked about earlier with the Land Warrior program.
What we’ve seen with the Land Warrior program, which has been in development for over ten years, is a deployment of those portable devices that we provide to the infantry soldier with a connection back to the operations center and also with his peers in the field.
So we’re seeing the deployment of those products in the field. The feedback from users about those products indicates that because the development time was so long, the basic processor speed for a lot of these portable devices is not where it should be.
It was a state of the art processor speed ten years ago but it isn’t state of the art speed today. Also, with all these devices carried by the soldier in the field there may actually be information overload. We’re providing them with too much data and more data then they actually need, especially when they’re in a tactical situation.
Bill Standen : That is an excellent point. Some of the things we’ve seen as a trend, as Jeff mentioned, we are supplying information for the sake of information. Ten years ago, it was “give me power, regulate it, and make it reliable.” Now it’s, “I want a communications bus and I want to see the fan speed and I want to see what’s going on with the cooling and other details.”
We’re happy to provide that information but you’ve got to wonder if it’s just information for the sake of information.
Ralph Wise : One of the things we’ve seen certainly is along the lines of what Jeff mentioned. For example, one of the radio programs that we’ve been supporting is the joint tactical radio system (JTRS) for a variety of suppliers.
And when you read about why soldiers aren’t buying JTRS which is supposed to improve the interconnectedness of information and data, you find out that soldiers need the Single Channel Ground and Airborne Radio System (SINCGARS) because that’s what they buy since JTRS isn’t ready. The reason it’s not ready is because the military has continued to put more technical requirements on the radios, pushing back availability.
Unfortunately, the soldiers need something now. So what they buy now is SINCGARS which have gone through several upgrades. What they really would like is JTRS. The reason JTRSs has limited availability is because it’s not ready yet and the reason it’s not ready yet is because technically it’s not ready. As new communication and location technology emerges, the requirements of JTRS change.
So we see this as what we call a death spiral. And, JTRS is one of those situations where, we hope it comes out of its death spiral but it doesn’t look like it’s going to in the near future.
Gordon Hunt :I think you see that kind of cycle in many different programs. Everybody knows they want to hook all these systems together or they want to make this sensor or that weapon system accessible to remote users, or, a unmanned aerial vehicle (UAV) that’s flying over should have its video available on some soldier’s PDA even though he’s not controlling it.
There are all these different visions and I think a lot of systems aren’t being pushed out. There’re always continued development but if you hold onto the way these things were integrated before and the way these systems were built in the past, it was a monolithic event. For example, here is the system and I can draw boxes around it. It is what it is and it’s been integrated and tested.
Well, in this fully networked world, you really can’t draw those boxes around the system anymore and we still want to do that. I see contractors and integrators wanting to draw those boxes and test the system but the system doesn’t exist anymore so that methodology of deploying and shipping product doesn’t really apply. However, I think that’s how many programs are deploying and shipping product.
There are continually evolving requirements and, which means “oh yes, you have to integrate with this thing now and you’ve got to hook to that and because you hooked to platform B, you also get platform C and D by default and you’re hooked to all of those.”
So, I think at some point, we need to step back and look at a continual evolution – kind of like a continual deployment process, something that allows systems to be deployed or new modules. This is a real hard challenge, but don’t get me wrong, I think that that’s where these things need to go otherwise, nothing will be released in the future.
Electronic Products : Is it because the system is a moving target?
Gordon Hunt : It takes a year or more and, in many cases, years to deploy system and by that time, requirements have evolved with a number of things that integrate to it. For example, if we just hook it up to this thing, we have these new capabilities. Of course, you would say, well let’s hook it up to that thing.
So, how do you test, certify, and deploy something that keeps getting new interconnections? How do you actually test that? We haven’t answered that question.
Ross Smith : There is a program that we’ve been involved in with the army. And there’s been some discussion about Land Warrior. We’re not really involved in Land Warrior but we are involved in Future Force Warrior which is the next design beyond Land Warrior. They’re using our Thermite computer as a soldier worn system.
The army conducts this experiment annually at Fort Benning and other places called the Aerosault Expeditionary Force Exercises (AEFE) where they take all kinds of technologies, and try them. The things that work well they’ll stick some more funding on, and things that don’t they say, “Well that was an interesting experiment but it didn’t really work well.”
We are seeing some very positive results from that. But it’s kind of a rogue part of the army that’s doing that. It’s in support of the rapid deployment force and we’re seeing some good results from it.
So, there is at least some hope for these things that rely on these gigantic programs like JTRS or future combat systems. They seem to get a life of their own and be to some degree, be removed from what the war fighter needs. If you look at the deployment timeframes, people don’t really care that much about capabilities that come alive in 2020. They’re interested in what gets into the field in the next year or two.
Electronic Products : Military and aerospace organizations must comply with IPV6 because security needs compel the change. The federal government is on a mission to upgrade IPV4 to IPV6. This represents the new generation of the Internet protocol mandated by the 2005 directive from the U.S. Office of Management and Budget.
In this equation, military and aerospace organizations, as well as defense agencies, are particularly sensitive to the potential new national and global defense advantage that IPV6 compliance offers.
What are the challenges for the transition to IPV6?
Gordon Hunt : I can offer a few brief comments. IPV6, the mandate’s been in place for awhile and actually most operating systems have an IPV6 stack. Most hardware has – or many hardware platforms have an IPV6 stack embedded in them.
So at a hardware infrastructure layer, a lot of it’s there. Certainly at a switching radio modem there’s some work to be done. But on a middleware layer, what we see really is, I think, the switch to IPV6 will be fairly straight forward, however, I don’t think initially all of the added benefits of IPV6 are going to be fully realized and these would include things like leveraging a traffic class which would let you capture packet priority, there’s a flow label that lets you do special handling so that you could partition your network.
You also might have a wireless network that has full mission-critical time-sensitive data as well as an ongoing video teleconference on it.
And the idea is that you don’t have to have different dedicated network links. You can just have one big network link and everybody will play nice in that space. And they see IPV6 as being as the way forward.
But I think it will take a lot less time to deploy the hardware. It’ll take, I think, significant time to properly leverage that hardware and the new protocol.
Electronic Products : Are you affected by current International Traffic in Arms Regulation or ITAR, restrictions and how?
Dane DeLozier : We traditionally haven’t been affected by ITAR; however in the last 12 or 18 months that request has come up for us. Again, we’re dealing in power. It’s probably considered from many perspectives to be sort of a low technology arena and not necessarily something that’s a high security risk.
But just by virtue of a designation on an RFP and there’s an ITAR restriction on the program that may or may not be necessary.
It kind of gets pushed down to us and then we have to respond to that. That said, it can be a daunting task drilling down into your supply base to control all aspects of ITAR.
One of the interesting things that we’ve seen is that the major contractors of the industry are struggling to find good vendor choices and some of that challenge is the result of the ITAR regulations. The erosion of the manufacturing base here in the United States and, well, in North America particularly, has been devastating to the number of choices that our major contractors have.
We haven’t been invited to participate in any of vendor development strategies yet, but we suspect that it won’t be long before the large contractors will have to form some sort of a supplier development consortium. Here they can actually cultivate and incentivize suppliers to jump into the market so that they once again have domestic sources.
We know that some of those consortiums have already begun. It just hasn’t quite touched us yet and we fully expect that it will though. It’s just a real reaction of those contractors to try to cultivate options in their vendor base.
Ross Smith : There is one such alliance that has started which is the Supplier Excellence Alliance (SEA http://www.seaonline.org) spearheaded by Boeing, Lockheed, Northrup and others. But they haven’t even contemplated ITAR.
All they are really worried about are inventory turns and quality. But, the thing that you bring up about ITAR compliance hasn’t even been a topic on any of their materials.
However, the requirements are huge. We’re a small, 80-person company and we have a full-time export-compliance person spending his/her entire time sorting out export licenses and ITAR restrictions because if you hose up, you could end up with a very commercial product that you could sell all over the world being ITAR restricted. But because you haven’t filled out the right paperwork, you could end up with a very limited market or no market for your product as a result.
So anyone that’s building hardware or software needs to be very cognizant of what the ITAR implications are because they can be quite profound.
Ralph Wise : I definitely want to underscore that because for the last two or three years we’ve been heavily involved in trying to untangle the ITAR restrictions and regulations to understand specifically what we can export without a license and what is required to have a license.
And as a matter of fact, we tried a little experiment. We actually gave our products to two different attorneys to have them sort it out and both of them came back with different answers. One said that the products did have to comply with ITAR then we gave it to a separate set of attorneys who came back and said they did not have to comply with ITAR.
So, even the attorneys couldn’t make an agreement. What we did is we actually formed very strong ties with the State Department.
And worked with the State Department on a case by case basis and it was like pulling teeth, because they’re not incentivized to get licenses through with any type of speed.
So we found it to be an extreme hindrance but we always err on the side of caution, because the fines and the penalties for not following ITAR are extremely crippling.
Ross Smith : It’s $1 million per incident.
Ralph Wise : Yes, it is. So, and we’re a small company as well and it would affect us. So, we continue to struggle with it. And we looked at product design features and all types of things. But we still have to do it on a case by case basis.
Electronic Products : If the fines are so excessive, why isn’t there someone that you can go to? Some point of contact that is willing to help, incentivize, as you say?
Bill Standen : You can make a commodity jurisdiction request and that’s when you go to the State Department and say, “Look, this is my product. This is the description. This is what it is. Does it fall under the State Department or does it fall under the Commerce Department?”
But unless, unless you’ve got a really important product, a large shipment or something where they’ll be motivated, it will take some time. The restrictions aren’t very clear. You’ve got to hire attorneys and consultants to get through it.
And also it’s not clear even from an enforcement standpoint where you could have someone say, “Hold up the shipment,” and they are just enforcement personnel and they’re saying, “Okay, now you tell me, which jurisdiction has it.” That didn’t happen to us but I’ve heard horror stories of that happening.
Ralph Wise : Oh yes, it has happened. We’ve pulled shipments back.
You bring up a very good point. We’ve also taken the commodity jurisdiction route as well. And, certainly we wouldn’t consider our products as high tech as some of those on the call right now.
But as we start to embed data systems inside batteries and chargers, we are covering ourselves and erring on the side of caution so anything that, anything that even smells like it might be subjected to ITAR, we will consider it ITAR first as we undergo the commodities jurisdiction route. And in some cases that can take several months.
Ross Smith : We’re seeing some commodity jurisdictions (CJs) take between six and nine months.
Part of our check list when we’re doing a new product is getting the support people involved up front and hopefully they follow up on an existing product that has a CJ. Or, if it’s a new product, it’s “oh boy, here we go again.”
It’s a real mess, and I think we need the American Electronics Association (AEA, http://www.aeanet.org) or some big organization to try and take this on because each of us by ourselves, we’re powerless.
The big primes really don’t care so much about it because most of their sales happen overseas are foreign military sales.
And soon as it’s a Foreign Military Sales (FMS) all (ITAR) issues go away because the State Department works with you directly.
Bill Standen : Exactly right – it’s almost government to government. And so they don’t really care. It’s those of us that are really in the COTS world that are selling – trying to sell products basically that our products – whether it’s software or hardware or whatever – that face this issue.
And I think it’s mostly small businesses that suffer from this. And some of the bigger companies that build commercial products like I’m sure Rockwell-Collins faces this problem with its clients – avionics overseas or whatever. Wherever you have a capability, it could have ITAR technology in it.
And even if it doesn’t, we have to go through all these hoops to prove that it doesn’t.
Gordon Hunt : We’re in the software infrastructure business and we run into this almost – I don’t want to say daily – but very, very frequently where we get involved with a contractor – defense contractor – and they want certain modifications done to the core software products and we have to be very careful about what we do and don’t add into our core product.
We don’t want to bifurcate our product and have 18 different versions of it because that becomes a support nightmare. But we still need to add certain capabilities or certain infrastructure elements to the core software product and, that may fall under ITAR so we are very, very careful about how we monitor our product even to the point of probably not taking on certain work just to avoid this issue altogether.
Ross Smith : We have gone to the extremes of compartmentalizing our products. We have an export restricted version of our products in some cases, and one that’s not.
And the one that is export restricted – you can’t buy that part unless you have an export license. And if you are a foreign military customer and want us to do any work for that on your behalf, it is considered a “defense service” that requires a technical assistance agreement (TAA). For a small company that’s probably the biggest burden that we face in terms of government regulations.
It’s a lot worse then safety compliance or CE or anything else. This is a big issue.
Gordon Hunt : I guess you got us going Paul.
Electronic Products : That sounded like it was a topic for another time as well. Well gentlemen, you did fantastically. I applaud you for being so forthcoming about a lot of issues.
It is with sadness that we inform you that Bill Standen, VP of Marketing and Sales at Martek Power, passed away suddenly on February 10, 2008. We will miss him.
Advertisement
