We just announced today that our partner, Communications Research Centre Canada (CRC) successfully ported a complete JTRS radio system, including an APCO P25 waveform, to an Android handset.

In one day.

They were able to do this because the Software Communications Architecture (SCA) uses CORBA as the communications framework. We spent the time and effort to port ORBexpress to the Android platform, so all CRC needed to do was get our ORBexpress for Android software to take care of the detailed communications architecture of the application.

This successful port by CRC shows the power of the SCA, and in particular the power of using a communications framework abstraction like ORBexpress. Moving to new devices, new versions of operating systems, new versions of compilers, etc., becomes easy because we do the hard work for you.

This also brings a new level of capability to the public-safety radio market, which is very price sensitive. CRC's work shows that public-safety radio manufacturers can take advantage of all of the benefits and new capabilities offered by software-defined radios, while keeping costs to a minimum by using commercial off-the-shelf hardware.

We'd love to talk to you more about how using ORBexpress can make your radio development faster, easier and cheaper. Ask us!

Joe

We just announced today that our partner Communications Research Centre successfully ported an entire software defined radio, including the core framework and full waveform, to an Android handset.

This SDR was based on the JTRS Software Communications Architecture, which uses CORBA as the communications framework. There's been some talk recently that CORBA might not be suitable for smaller form factor radios. That might be true for a lot of enterprise-type ORBs, that are relatively big, slow and cumbersome. ORBexpress, however, was built from the ground up for hard real-time and embedded systems. We always knew that ORBexpress would be ideal for very small form factor radios, but until we could demonstrate it in practice it just was a difference of opinion.

That's why we are so delighted in what CRC has accomplished. They ported a full core framework, a full waveform (with all the modulation and demodulation, etc., running on the Android platform) and the entire radio in just one day. Because OIS had already done all of the hard work in porting ORBexpress to the Android platform, their port of their SDR application went smoothly and without a hitch.

All of this ran smoothly, with long battery life, on a single core ARM processor. That's right - no DSP, no FPGA, just a GPP. This successful test demonstrates the power of the portability of the SCA. By using a standards-based communications framework like ORBexpress, next generation radios can take advantage of new smaller and lightweight form factors without rewriting their software.

This means new features and new form factors will get to the warfighter faster and more reliably. A win by any measure.

Joe

We just announced that ORBexpress now supports Wind River's VxWorks 6.9 with full symmetric multiprocessing capability. A lot of our customers are letting us know that they believe their next projects, or the next generation of their existing projects, will use a multicore processor. All you need to do is look at how smartphones are developing. The current trend is to move to dual-core ARM processors, and there are already quad-core ARM processors available.

In order to keep battery usage and heat down, it makes much more sense to add additional cores without dramatically ramping up the GHz of the processor. That way, you get a lot more MIPS (millions of instructions per second) without eating up battery life. This is one of the many benefits of the relentless march of Moore's Law.

ORBexpress was designed, architected and built from the very beginning to optimize processing distributed over multiple processors. Its native multi-threaded architecture is ideal for multicore applications. This means that software developers using multi-threaded ORBexpress in an application running on a single core processor can reap the benefits of moving to a multicore processor without rewriting their application. They literally need to change only one line of code to enable dramatic performance improvements (assuming that the underlying operating system supports multicore).

Feel free to contact us to learn more about the specific performance improvements that your system might realize in using ORBexpress.

Joe

We're delighted to announce that the good folks over at PC/104 and Small Form Factors magazine have selected ORBexpress for Android for their Editor's Choice award. With all of the issues developers face in connecting their applications across a range of different devices running different operating systems, processors and communication methods, they singled out ORBexpress for Android for its ability to bridge these gaps easily with a small footprint and lightning fast performance.

It's always nice to be recognized, and we'd like to thank the editors of PC/104 and Small Form Factors magazine for their recognition of our hard work.

Joe

Several projects that I have seen while supporting ORBexpress have implemented a fairly complex processing architecture and still easily met stringent performance requirements. One commonality among these successful projects is that they identified and addressed architectural risks early on in the process.

Lots of projects, influenced by the "waterfall" development model, don't try to run any of their pieces together until all or most of the pieces have been developed. In the ensuing integration nightmare, new requirements are discovered and design flaws are uncovered -- with no time left to deal with them. In particular, performance bottlenecks or unexpected error paths are discovered only at this late stage…or in the words of Homer Simpson, D’OH.

Unlike the sitcom character, you can avoid this experience. To help ensure a smooth development that meets their proposed schedule, smarter projects develop a "skeleton" of the system early in the project. These can have many forms, but generally include all of the major components present, as token "stubs", and exercise all of the major data flow paths with "dummy data". The closer this “skeleton” is to the production processing environment, the better, but compromises are often necessary. The target hardware may not be available, the target operating system may not be easy to test on, or the communications infrastructure may be missing.

CORBA can help in all of these situations. It offers a degree of transparency that allows different processing hardware, different operating systems, and different communications to be used in the initial architectural prototype. For example, many ORBexpress users prototype their system on a standalone Windows or Linux machine, and then gradually move each component to their actual target operating system. The location transparency of ORBexpress makes it easy for developers to do this.

Performance is another aspect that can be explored and verified with a prototype using ORBexpress. The initial prototype can validate that sufficient bandwidth exists in the infrastructure, that sufficient feedback is present to handle congestion, and that fan-in and fan-out points don't introduce excessive latency. As the implementation proceeds, stubs and dummy data can gradually be replaced by more complete data representations and realistic processing algorithms.

Finally, an architectural prototype gives you something to show the customer. Customers are much more assured by a lash-up that just "blinks the lights" than all the progress charts showing thousands of lines of code you have developed to date. Incremental progress can be demonstrated by blinking the lights in ever more sophisticated patterns.

It is important that projects port the prototype skeleton to the actual target as it becomes available, since the benefit of transparency may hide real issues in the architecture. For example, calls on a single system never fail due to unavailability of the called subsystem -- the caller would also have failed! Thus these error paths cannot be discovered or exercised after discovery.

Projects that start with a skeletal architectural prototype have the opportunity to explore performance, reliability, and platform-application integration issues at an early stage of the project before a significant part of the application is developed. If the "bones" are strong and well connected, the application will be more robust when it is "fleshed out".

Once again, ORBexpress has been picked as the ORB of choice for advanced, next generation radios and waveforms. We announced today that ITT Electronics Systems chose ORBexpress for its next generation software defined radios.

The JTRS program picked ITT to develop and build the Soldier Radio Waveform (SRW). This is an incredibly strategic piece in the US DoD's efforts to build a next generation mobile and adaptive communications network. The SRW will be used in hundreds of thousands of radios built by a lot of different companies. It massively advances the state-of-the-art on a number of different levels, including a two orders of magnitude improvement in throughput as well as dynamic, ad-hoc networking.

ITT also developed and built three different radios conforming to the JTRS radio specfication, the SCA. Their Rifleman Radio is a lightweight body-worn radio that lets Marines that have left their vehicles communicate with each other and their surrounding vehicles (even unmanned vehicles!). Their Soldier Radio lets soldiers do everything from simple push-to-talk communications to networked data communications. Their SideHat radio enables legacy SINCGARS radios to take advantage of these new networks buy adding a JTRS-compliant second channel to the ITT SINCGARS radios that are already used on more than 100 different vehicle platforms.

All of this was done by ITT with a laser-like focus on producing these radios in very small form factors. ITT was able to meet their goal by using the small footprint, high throughput performance of ORBexpress while taking advantage of our quick and responsive support. Kudos to ITT for a job well done (and kudos to our development and support engineers).

Whenever I talk with my customers on the phone, at their site, or trade shows, sooner or later the discussion turns to “CORBA overhead” and what are we doing about it? Dig a little deeper and their real concern is some facet of message latency.  How many messages can their application send in some period of time? Or the time it takes to send a single message, or the order and reliability of message processing.

Many factors contribute to message latency. The usual suspects being; application architecture, third party libraries, operating systems, and network protocols.  As a middleware for distributed inter-process communication, CORBA provides an abstraction layer that protects developers from many of these criminal elements.  While this abstraction allows developers to build features instead of infrastructure, it also causes CORBA overhead to get blamed for their bad behavior.

Over the course of my next few posts, I’ll explore each of these shady characters in more detail. Discussing their roles, interactions, and trade-offs, hopefully helping you to identify which suspect to squeeze to improve message latency.

Charlie