As more and more devices become connected to the cloud of ubiquitous Internet access, engineers are looking to capitalize on this connectivity without having to develop the technologies themselves. Using a set of common APIs and IP platforms to enable communication with cloud services can help engineers deliver always-connected products with enhanced functionality.

What do you think of when you hear the word “cloud?” Marketing speak? Just another way to reduce costs? A revolution in the delivery of services? A better way to run a business and design products? Whatever engineers think about the concept of the cloud, they will soon face a concrete problem: taking a previously stand-alone product and turning it into a connected device.

The cloud is an inevitable trend that is already becoming mainstream. Our society is increasingly online, with consumers using computer browsers, second screening in front of TVs, and accessing e-mail and social media when mobile. Ever-faster home, business, and mobile Internet access has led to an age when logging on is the fastest and most engaging way of getting work done and being entertained.

Tablets, phones, and TVs grab the headlines now, but in the near future everything will be connected. The next wave will be in consumer electronics, as radios, cameras, photo frames, printers, and more become connected to the cloud. Once the big money/big R&D consumer electronics and home automation segments have blazed the trail, everything else will follow. Vertical industries such as retail, health care, finance, utilities, and instrumentation will all increasingly use wireless, with cellular or Wi-Fi machine-to-machine as their primary connectivity option.

Development questions

In evaluating the use cases for Flow Technology, a comprehensive IP platform family that connects devices to the cloud using both Internet and broadcast channels, engineers considered a simple question: What would be an ideal offering for time-starved engineering teams who need the advantages of cloud connectivity but gain no upside from developing those technologies themselves?

The answer was an end-to-end infrastructure for connecting devices to cloud-based services. While the relative ease of providing on-chip Wi-Fi (and ultimately other connectivity standards) already enables a device to connect to the cloud, several important questions remain:

• What URL does the device connect to?
• How do you set up a user account?
• How do you update software?
• How do you control the device from a browser or app in the cloud?
• How do you stream content, and where do you get content from?

Each of these questions represents a complex issue that not every company has the resources to resolve.

APIs enable connections

The key to successfully enabling devices to easily communicate with cloud services is to develop a set of APIs allowing anyone writing an app on a connected device to answer all of the aforementioned questions, as well as to be extensible to many more functions.

Using those APIs, devices can connect to an ecosystem of third-party partners providing payment systems, streamed content, health care, security, and more. For example, 7digital (content) and MiPay (payment) are helping provide those services to device manufacturers.

The APIs must talk to both the cloud services and the hardware devices. To enable this, Imagination Technologies created two bookending technologies: a cloud portal (FlowWorld) and a connected processor (METAflow), illustrated in Figure 1. The idea behind the model is that the portal’s unique fit to the connected processor enables a higher degree of efficiency, consistency, and utility for developing devices delivering real-time and always-connected services.

Simple to implement, APIs enable ecosystem partners to rapidly develop and deploy a diverse range of embedded applications supported by Web services. Any silicon device manufacturer can license these technologies, or product manufacturers can buy silicon devices from licensees and then use them to connect to generic or customized Web services created using APIs.

Flow Technology includes highly integrated, licensable, connected processor IP platform hardware complemented by a range of Internet-based enabling technologies and a portfolio of cloud-based resources/services. The technology includes essential baseline product services such as Update for in-field robust software updates, as well as enhanced services such as Radio for adding advanced features to end products. A portal delivers both baseline and enhanced services using a series of APIs through which partners can centrally control and manage service configurations for any METAflow-based connected product.

Thanks to an advanced template-based implementation, the portal can be configured to enable service providers to maximize the solution’s services while creating a highly customized user experience and retaining compatibility with other Flow Technology-based products.

IP and hardware platforms for the cloud

Engineers experimented with these technologies in Imagination Technologies’ consumer electronics brand, PURE, and reported any issues before the product family was offered to a wider customer base.

The portal powers the PURE Lounge cloud music service (Figure 2), which delivers radio, streaming, and apps to connected processor-enabled radios. Using this kind of platform, developers can prototype and deploy truly connected products and solutions without requiring the incredibly broad range of engineering and commercial know-how and resources usually only found in the industry’s biggest players.

Other devices can help those looking to solve the hardware side of the equation. For example, the XENIF TZ1090 connected processor from Toumaz combines a Meta HTP or MTP processor running Linux, MeOS, Android, or other third-party Operating System (OS) with a highly optimized Ensigma UCCP communications IP core running 802.11 Wi-Fi.

The Meta HTP221-dp2 Minimorph development platform (Figure 3) helps engineers gain experience with this technology. The 10 cm x 10 cm board supports the full set of Flow APIs and includes interfaces and peripherals such as an SD card, Wi-Fi, HDMI, and USB, plus headers for a range of TV or radio tuners.

The Minimorph software development kit includes the CODESCAPE debugger with Linux application debug support. It ships with working tutorials and documentation plus examples that familiarize developers with Meta’s architecture and DSP features. Debugging is accessed via an Ethernet or JTAG port.

Minimorph includes a port of the latest open-source Linux OS for Meta processors, allowing developers to access both the wealth of application and device support available for Linux-based systems and the real-time 32-bit DSP capabilities of the Meta processor.

The next wave of connected embedded devices

The increasingly broad array of highly portable application platforms such as Linux, Android, and sophisticated Real-Time Operating Systems (RTOSs) is prompting companies to reevaluate how they can create the next wave of connected embedded products. Ultimately, the best result for the industry will be a set of common platforms, APIs, and devices on which cloud products are built.

If this happens, as it has in the graphics space where APIs such as OpenGL have standardized interactions between GPUs and applications, then engineers can focus on their unique domain values and create compelling products that are enriched and revitalized by this ubiquitous connectivity technology. These cloud-based devices will deliver functionality using an optimal mix of local and Internet resources.

Tony King-Smith is VP of marketing at Imagination Technologies. He was previously with Panasonic, where he was involved in global business and technology development in the consumer, automotive, and mobile phone market segments. Tony has also held senior management positions at Renesas (Hitachi), LSI Logic, Inmos, and British Aerospace.

Imagination Technologies +44 (0) 1923 260511 info@imgtec.com Twitter: @ImaginationPR Blog: http://withimagination.imgtec.com www.imgtec.com

]]> http://tech.opensystemsmedia.com/android/2011/12/ip-platforms-enable-cloud-connected-device-development/feed/ 0 http://www.embedded-computing.com/articles/id/?5458 http://www.embedded-computing.com/articles/id/?5458#comments Fri, 09 Dec 2011 15:00:00 +0000 Michael McNamara, Cadence Design Systems http://tech.opensystemsmedia.com/android/?guid=3096959a3a91784901b70382581aabaf

Editor’s note: Started in 1969 by Dr. Paul Broome, ENSCO is an S Corporation based in Falls Church, Virginia with 600 employees and a focus on national security. Of the company’s five divisions focusing on transportation, security, and aerospace and defense, the Innovative Systems Solutions division found that it was often “synergistically” running into the product IData by Quantum3D. ENSCO put together a deal to acquire Quantum3D’s IData and IGL 178 product lines and associated employees. The merger was announced earlier this year, shortly before Military Embedded Systems talked with Ray Niacaris, Director of Operations and Sales for the newly formed IData Visual Systems Inc. subsidiary of ENSCO Inc.

We know that ENSCO provides scientific and engineering technologies for aerospace and defense, among other industries, but why buy Quantum3D’s IData and IGL product lines?

NIACARIS: In a word: synergy. As we moved more and more into certification projects, it became apparent to us that we needed much more certification expertise. And the IData product line needed to add tactical digital moving map products and ENSCO had that technology in house, but not a vehicle to bring that technology to market. The IData product line was the vehicle to accomplish that. Finally, we had essentially the same customer base, so it would be a seamless integration effort with existing IData customers.

What exactly is ENSCO buying?

NIACARIS: ENSCO purchased all the IData intellectual property and all the IGL intellectual property. They also took over all existing customer support agreements and open NRE projects, in addition to all hardware, computer resources, marketing materials, customer databases, trade-show material, and anything else that was associated with the IData and IGL products. ENSCO also took on Quantum3D employees who were dedicated to the IData and IGL product lines.

What is the IData product line, and which problem(s) does it solve in the avionics industry?

NIACARIS: The IData family of products addresses the HMI needs of the avionics industry. Unlike most tools that create an executable file that needs to be linked to the target system’s software to create a contiguous executable, IData has an executable library, fully certifiable, that processes data and comprises HMI behavior and graphics. This data can be dynamically downloaded to the target system in real time, while the target system is fully operational, thus negating the need to shut down the target system.

And the IGL product family addresses another set of common issues related to embedded cockpit displays: namely heat, power, and obsolescence. IGL is a software-based GPI that supports the Kronos ES/SC subset of the OpenGL standard. Much of the graphics display work can be accomplished with IGL, such as the primary flight display. IGL is a software library, fully certifiable, that runs on the target system, processes OGL commands, and drives the frame buffer. It can be used in conjunction with a system GPU or run stand-alone. In a partitioned memory application, it can isolate the graphics display tasks and allow different FAA certification levels to be on the same display. Since IGL utilizes CPU cycles to perform its functions, the need for a separate GPU chip and its associated power and heat issues are eliminated. Even more importantly, since IGL is software, it can easily meet the 20-year product life-cycle requirement.

Who/what are the competing solutions to IData?

NIACARIS: With the IGL product line, there really is not a directly competitive product. IGL mainly competes with hardware-based GPUs (chips). In that respect, IGL cannot support all of the functions at the same performance levels that a GPU can. However, for a number of avionics applications, IGL can perform the required functions at the desired level of performance.

Although none of the competition uses the architectural approach of IData, their offerings address the same issues/design problems that IData does. Among these companies are Presagis: VAPS xt, Disti: Glstudio, Altia: Altia Design (mainly focused in the automotive market); Esterel: SCADE Display. I have noticed an increasing desire by manufacturers to use tools, but issues arise when programmers who developed the custom application decide to move on and the knowledge behind that custom implementation moves with them.

What about code reuse?

NIACARIS: There are many applications written with tools no longer supported, and customers are faced with what to do with legacy software. One of the first HMI tools on the market was VAPS. Many applications were written using this tool, and customers would like to have a way to import those legacy applications onto a new platform that provides them a future and increased capability and performance. IData actually has an importer that can read a customer’s data files created with a tool like VAPS and convert them to the IData tool set. Recent migrations have resulted in a minimum of a 2x performance increase as a result of the re-hosting. Still other customers have found it rather easy to just redo the display applications in IData.

Since IData does not generate code, but rather data that renders an engine on the embedded target system, the identical HMI design can be used on a multitude of target systems of different capabilities because the target system will use its graphical and CPU resources to display the HMI design and behavior. In other words, one need not be concerned about the target system when doing the HMI development.

Talk about some of the latest market technologies, and how they affect IData and why.

NIACARIS: Our business used to be driven by technologies developed by the gaming industry, and that is still the case to a certain extent. However, what used to be a simple cell phone is no longer the case. The use of a cell phone to make calls is often considered incidental, rather than the key component. It would be a real challenge today to find a cell phone that just makes calls. The challenges of these mobile devices are many, but chief among them is power or battery life. This market in many ways is now driving our industry.

Until a few short years ago, a multi-touch MFD was out of the question and a touch panel was rare, with the preference still being bezel buttons. We are now seeing 3D panels that do not require special glasses, and we now need to write applications that rely on touch and multi-touch GUIs. Android is now considered as a development platform that we are required to support. It seemed to happen almost overnight that EFBs were being built on top of iPad technology, and that product itself was only introduced a year ago. The complexity of the graphics required in cockpit displays requires more and more powerful GPUs, and these GPUs need to be around to support 20-year product life cycles, or be so driven by standards-based design that applications can move seamlessly from one hardware platform to another. Those tools that can address that portability will survive in the years ahead.

HMI tool vendors need to form strategic relationships with hardware vendors and RTOS and middleware vendors to ensure that they are all working in concert to drive new technologies and provide the very best solutions for user/machine interactions.

What do you see the future holding in this area of HMI tools, safety-critical software, and so on?

NIACARIS: As we move forward toward advanced cockpits, we can be fairly certain the future will yield new ways to provide the aircraft pilots complex data about their surroundings in an instantly recognizable format. That format will most likely take the form of some type of graphical display. The trick will be presenting that information in an easy-to-comprehend manner and in a timely fashion.

IData Visual Systems, Inc. is currently working on a concept called “combined vision systems.” This is a complex concept that requires combining high-speed sensor technology with high-performance, real-time visual data capture (i.e. satellite imagery), synthesized terrain data, real-time weather data, radio identification data, ground-based situational data, and other types of data still yet to be identified. These data need to be combined in a single display to create a synergistic awareness to the flight deck far beyond the levels of information displays currently in use. Each data feed can fill in or enhance the data present from other sources including, of course, the view out of the flight deck windows and the pilot’s inherent knowledge of their surroundings.

What advantages will ENSCO’s acquisition of IData provide to the embedded industry?

NIACARIS: To begin with, ENSCO has primarily been a service-based company, while IData has been focused on products. As the products produced by IData evolved more and more into the realm of safety-critical design, it became readily apparent that it must “staff up” to engage in that type of business. However, ENSCO already had the staff, reputation, and track record to provide the type of support necessary to pursue that business. Today IData Visual Systems can support fully certified cockpit display programs.

Additionally, although IData has capability to overlay weather data in its IData HMI product, until the acquisition by ENSCO, IData did not work with sources of weather-related expertise. ENSCO has an extensive weather research group and supplies weather data to NASA as well as a major airline.

IData has not been engaged in the rail industry, yet ENSCO has been working with the rail industry for many years. In fact, a quick visit to the ENSCO website yields many areas where ENSCO’s established businesses can benefit from the use of IData products and vice versa.

Ray Niacaris is Director of Operations and Sales at IData Visual Systems Inc., a newly formed subsidiary of ENSCO Inc. He has more than 35 years of experience in real-time embedded systems and computer graphics. Ray has degrees in EE and CS from the Illinois Institute of Technology, where he graduated with honors. He has completed advanced studies in product design and held the position of Studio Professor at the Illinois Institute of Design. Contact him at rayn@idatavs.com.

ENSCO, Inc. 909-593-2055 www.ensco.com

]]> http://tech.opensystemsmedia.com/android/2011/10/the-impetus-for-the-quantum3d-product-lines-acquisition-in-one-word-synergy-qa-with-ray-niacaris-director-of-operations-and-sales-at-idata-visual-systems-inc-a-subsidiary-of-en/feed/ 0 http://www.mil-embedded.com/articles/id/?5347 http://www.mil-embedded.com/articles/id/?5347#comments Fri, 02 Sep 2011 15:00:00 +0000 Michael Howard, QinetiQ North America http://tech.opensystemsmedia.com/android/?guid=541ee73c59057f37dfab55e50857fc74

Mobile applications are just starting to earn their way into the “trusted” status of the military IT toolbox. But given the growing use of smartphones on the battlefield, can a smartphone do more than just monitor a network or provide secure chat? Could it actually heighten situational awareness to help save warfighter lives or even provide aid in combat fire scenarios? The answer is a resounding “yes,” and a Composable Handheld Android Platform (CHAP) comprising a Call For Fire (CFF) Mission Thread is key. (U.S. Army photo by Heather Vann)

Despite technological advances across the board, the Department of Defense continues to grapple with a familiar capability gap – situational awareness, particularly the availability to deploy small, dispersed, mobile units. While situational awareness tools are now heavily automated, the route that many DoD technologies are taking, this automation emerged in the matrix of legacy command and control architecture with thick clients, voice communications, authoritative data sources, and centralized command centers. However, doctrine and operational practice have now outgrown such an architecture. Small, highly mobile, increasingly autonomous units (and even individuals) are intended to operate in a net-centric fashion, but legacy issues of network infrastructure, heavy systems, and lack of access to data continue to limit mobile situational awareness.

Combat fire support poses a particularly tough challenge for mobile units. Its stringent requirements for timeliness and accuracy and inherent lethality as well as dependence on an accurate operational picture suggest that if a system works well and reliably for fire support, it should also lend itself to other domains. Such a mobile combat fire support system now exists for military use, the Composable Handheld Android Platform (CHAP), which comprises a Call For Fire (CFF) Mission Thread, Infrastructure as a Service (IaaS), Software as a Service (SaaS), a Web portal, and an Android or iPhone smartphone application and associated services. The following discussion examines the different components that enable a CFF to be executed from the CHAP, from functionality of the device to the makeup of the systems behind CHAP.

Eyes on situational awareness

Complete situational awareness comes from eyes on a target (for example, video feeds from UASs), Blue Force and Red Force locations and descriptions, current and accurate imagery/maps, and local area intelligence. With the aforementioned technology unified into a single system, CHAP provides an observer with necessary intelligence, as well as the ability to modify, delete, or create tracks (actual moving targets) directly from the mobile device. Fire support can now be called in through a Droid or iPhone application, simply by confirming the target via the touch-screen; this smartphone-based support also gives the warfighter access to other intelligence via data services functionality, including chatting with other units currently connected to CHAP in the cloud. A screenshot of the soldier’s view can be seen in Figure 1.

When a target is created, it is reported through the cloud, processed through a Complex Event Processing (CEP) engine, and sent to the secure commander portal in real time for review and authorization. Via the portal, the operation commander can view an entire Common Operational Picture (COP), which runs as SaaS within the IaaS. Additionally, any authorized users in the portal can create a customized view, or User Defined Operational Picture (UDOP). The user can select from a library of widgets (such as Google Earth and NASA World Wind) to build their UDOP, which can be seen in the screenshot of the Commander’s view (Figure 2).

The prime question remains, however: What does each disparate piece of technology bring to the table, ultimately enabling mobile situational awareness for the warfighter? We’ll start by examining the CFF Mission Thread.

Live fire – CFF Mission Thread

The CFF Mission Thread is a series of documented processes, involving dozens of parallel systems and applications as well as high command review built around an observer (for example, a warfighter) using a smartphone to call for fire. This is done simply by the user holding his/her finger on the target for a few milliseconds until the command is transmitted to the cloud for analysis, against a target, whether an enemy vehicle, strongpoint, building, or unit. The Mission Thread is the backbone of CHAP, allowing the warfighter to call for, and receive, fire support in a hostile situation. For the Mission Thread to function as needed, however, several criteria must be met.

First and foremost, the observer must be connected to the military network and the supporting applications, like the Address Book, must be online and functional. Next, the operation commander’s criteria and Fire Support Coordinating Measures (FSCMs) must be readily established guidelines for the type of fire support to be received: how this incoming fire will affect nearby operations and whether or not air support is to be received. Finally, the observer must have a laser (used to “paint” the target/targets), and there must be weapons positioned in the area of operations to actually fire on the target.

When these criteria are met, fire support can be received. As for the type of fire support, Precision Guided Munitions (PGMs) must be employed, which provide near-pinpoint accuracy to the observed target. In this case, PGMs can include supporting fire from howitzers, tanks, unmanned aerial systems (like the Predator drone), and attack helicopters.

To prevent unauthorized use or interception, the Droid or iPhone used by the observer could be equipped with a Type I Encryption Sleeve. Currently undergoing prototype testing with NSA, this is similar to a standard smartphone case or iPhone “powerpack” that locks around the outside of the smartphone, providing Type I encryption capabilities to a typically unsecured device.

Fire from the cloud

CHAP relies heavily on the cloud for its flexibility and overall functionality to the warfighter, primarily via IaaS and SaaS. IaaS renders the virtual environment transparent to the end user, allowing updates to the applications (such as the Droid app, services, business rules engine, portal, and widgets) and the underlying infrastructure to occur without procuring physical memory, storage, or processing power. Meanwhile, SaaS enables easy deployment of COTS soft-ware for additional functionality within the technology. Enterprise services provide a foundation for interoperability among the capabilities deployed within the cloud environment and consist of eight separate services:

1. Discovery Service

2. Messaging Service supporting AMQP and Java Message Service (JMS)

3. Orchestration Service

4. Real-time Collaboration Service

5. User-facing Services

6. Security Services

7. Mediation Services

8. Enterprise Service Management (ESM)

Along with the aforementioned enterprise services, the Department of Defense’s Universal CORE (UCore) data model is also used, allowing the simulated data services running in the cloud to talk to each other. Additionally, UCore in this application is extended to support Track Metadata, Video MetaData, and Variable Message Framework (VMF) messages for position location, along with Keyhole Markup Language to support Google Earth Integration.

The simulated data services include multiple intelligence systems, including sensor data from remote monitoring units, video feeds from UASs and aircraft, maps, and other imagery. Most notably, the Global Command and Control System-Joint (GCCS-J), a DoD legacy system, is also run in the cloud as a simulated data source. To do this, a tracks service (an application/messaging service to transmit tracks/target information) was written on top of GCCS-J, allowing it to push its data into the cloud for use by the other cloud-based services.

For the final step in the cloud, a Universal Description Discovery and Integration (UDDI) registry stores all the services and their associated data models for CHAP, which allows the disparate systems making up CHAP to find the appropriate service when needed for a specific event, like an acquired target or a request for fire support. A CEP engine then processes these multiple events and messages to determine which should be acted upon, in conjunction with a Business Rule Management System (BRMS) that defines, deploys, and executes business rules for the system.

As an example, the CEP engine has a rule to easily let commanders see when a tank or other mobile firing platform is running low on ammo. More specifically, when a tank’s ammo threshold drops below 20, the affected tank turns blue, allowing commanders to easily see which tanks are friendly (blue), hostile (red), or low on ammo/resources (green). The Commander Portal contains a widget to view this on the Map for SA.

Forging ahead under fire

This technology was co-developed by QinetiQ North America and Red Hat in their internal research and development program. The current technology source code is available via projects within the DoD’s Forge.mil, including an Android project established during this technology’s development. The system described herein was developed to demonstrate the art of the possible for the current tactical and enterprise environment. The technology is being refined for deployment to warfighters who need near-real-time situational awareness – and that, of course, is every warfighter whose boots are on the ground.

Michael Howard is the Vice President of Advanced Enterprise System Solutions for QinetiQ North America’s Systems Engineering Group. He has been recognized throughout the DoD for his efforts in Service Oriented Architectures (SOAs), Master Data Management (MDM), System of Systems (SoS) Engineering, and SoS integration. He holds a BS in Computer Engineering from the University of South Carolina. Email: Michael.Howard@qinetiq-na.com.

QinetiQ North America 843-740-7456 www.qinetiq-na.com

]]> http://tech.opensystemsmedia.com/android/2011/09/combat-fire-support-and-situational-awareness-theres-a-smartphone-app-for-that/feed/ 0 http://www.mil-embedded.com/articles/id/?5349 http://www.mil-embedded.com/articles/id/?5349#comments Fri, 02 Sep 2011 15:00:00 +0000 Sharon Hess http://tech.opensystemsmedia.com/android/?guid=e50f60e46d41c665b20655ad90738cdc

Most of us in the embedded design realm have probably tucked a PowerPC, PowerQUICC, or some other Power Architecture incarnation into an application or system in our time. But where, oh where has Power Architecture ended up? While Intel ramps up and delivers its high-profile industry vision, Power.org is steadily and more quietly (for now) putting its pedal to the mettle to sustain and grow the Power Architecture road map. Editor Chris Ciufo recently sat down with Fawzi Behmann, Director of Marketing and Strategic Advisor at Power.org, to get an inside look at the organization: past, present, and future.

How did Power.org get started?

BEHMANN: As suppliers such as Motorola, Apple, and IBM were carrying out the goal of Power Architecture or PowerPC, the notion of Power.org arose, so that it would carry the ball in Power ISA. The focus would be conserving the Power Architecture and instruction set for both the embedded and the compute [markets]. Power.org would generate technical committees to develop various specifications that aid development by member companies. The organization would also encourage opportunities to promote the Power Architecture ecosystem. So Power.org came onto the scene back in 2005, with IBM and Freescale as founding members. And we recently celebrated PowerPC’s 20th anniversary.

How is Power.org doing in market share these days?

BEHMANN: The 2009 Processors market size for 32- and 64-bit processors was $63 billion. Then the Power Architecture market share [according to IMS research] is $4.4 billion of that (broken down by these segments):

• #1: 32-bit MPU
• #2: 64-bit CPU
• #2: 32-bit MCU
• #1: 32-bit FPGA
• #3: 64-bit MPU
• #3: ASIC and ASSP

Who are the members of Power.org?

BEHMANN: We have three levels: founder, sponsor, and participant. They could be on the silicon supplier level or they could be at the SoC level; they could be at the OS or they could be in the middle layer or in the higher-end or applicational solutions. We also collaborate with a variety of communities, like the Linux community, and with other standards development organizations.

We additionally consult with customers and with market researchers in terms of opportunities. But our technical committees try to focus on three things: 1) What would the road map look like? 2) How do we go about what matters in terms of software? and 3) What matters in terms of platform and ecosystem? So we try to work with the core members and ecosystem partners and developers. We have about 2,500 developers working with Power Architecture.

What is the biggest market that Power Architecture products find themselves in?

BEHMANN: I would say communications, networking, and enterprise servers. We are also strong in wireless infrastructure, strong on automation in terms of the application. Also, we have quite a presence in military, aerospace, and medical imaging. And certainly the automotive, industrial, and consumer markets are also strong for us.

What really drives Power Architecture behind the scenes?

BEHMANN: What drives Power Architecture more than anything is really the Power ISA or the Power Instruction Set Architecture because it’s 64-bit and 32-bit, addressable, and provides capabilities for developers to build an architecture that is scalable from a very low end to a high end. Today we’re deploying processors all the way from 60 MHz to 5 GHz. But with that, there’s a progression in terms of which capabilities we need to have in the instruction set.

Tell me more about the Power ISA progression you’ve mentioned.

BEHMANN: We’ve had a series of evolution in terms of Power ISA standards – 2.03 all the way to 2.06 – since the inception of Power.org. The 2.04, 5, and 6 address specific areas dealing with multicore virtualization, hypervisors, and energy management – which are really what future systems are pulling for now because they’re getting more complicated, more complex, more scalable, more multicore, utilizing multithreading, and so on.

When you say “Power Architecture,” what does that encompass exactly?

BEHMANN: The Power Brand is an umbrella brand that covers any emerging power product road map made by member companies. So Power7 was introduced last year to come on the Power Architecture, also Power EN [Edge of Network], PowerPC, QorIQ, PowerQUICC, and so on.

Not only that, the Power.org 2011 road map continues to demonstrate a great level of investment by member companies. From a timeline perspective, it covers processor product lines by silicon vendor: history, current, and future. And certainly you see a whole lineup of product lines for the both the 32-bit to 64-bit, as well as the commercial and the commercial licensable core.

What sort of specifications has Power.org released for Power ISA?

BEHMANN: One specification we have released is the Common Debug Interface, developed by member companies to help define different methods and impact the way of tracing and debugging based on embedded, as well as compute environments. Another specification is called Embedded Hypervisor. That defines the thin layer of the hypervisor that determines how to have multiple operating systems running over multiple cores and so on. We also have a specification called Virtual Platform, which enables software development before the availability of silicon.

These three areas and specifications tend to handle major achievements or core impact in terms of enablement, whereas things like our sPAPR specification have to do with rebooting devices. Also the ABI Documentation specification concerns the documentation related to the application binary interface. So sPAPR and ABI Documentation are more ancillary-type support and specifications.

Let’s talk trends. Android is everywhere these days. Is Power.org doing anything with Android?

BEHMANN: Yes, we had a showcase on Android activities and demonstrated that we had a special way of making it. Now we even have Android-based open source available to the developer community. We also have various initiatives in Android by Freescale [Android over MPC8536, Android over QorIQP1022, Android + MPC5521e, and Android + MPC5525] and IBM [Android over PowerPC460S, XGI (now SIS) Z11 graphics card, and AppliedMicro Canyonlands board] and third parties, which ported Android over Power Architecture.

What about cloud computing? That’s as much a water-cooler topic as Android these days.

BEHMANN: Yes, Power.org has also shown advancement in terms of a wireless network cloud system, through our research project based on [Software-Defined Radio]. That’s progressing actually from IBM Research in China.

But something else your audience might be interested in is IBM’s Watson computer, based on the Power7 processor within an optimized system running IBM DeepQA software developed by IBM. Watson, as you probably know, was featured on [the TV game show] “Jeopardy” and won the game, answering the questions in less than 3 seconds.

Interesting. So what are some of the other Power.org technical developments, such as with QorIQ, for example?

BEHMANN: Freescale has generated the QorIQ Qonverge basestation-on-a-chip, comprising the metro microcell, macro basestation, enterprise pico/femto, and home/SMB femto. One example of this is the PSC9130/31, a femtocell SoC solution. There’s also the PSC9132, a pico station. That solution is really an integration of not just Power Architecture, but also DSP, I/O, memory, switchback, and so on. And it provides a different type of scalability. Femto SoC accommodates 8-16 users, and pico and enterprise [products] accommodate up to 64 users.

What’s the different between pico and enterprise if they’re both up to 64 users?

BEHMANN: It’s a progression. For the enterprise, you could have a small enterprise, big enterprise, and so on. So you could have something 32, something 48, something 56, or whatever, all the way up to 64 users. So it’s really a mix between a medium to a larger type of cell.

Where do power considerations play into these basestations?

BEHMANN: In terms of pico versus macro, most of them are delivering lower cost and lower power – typically by almost 4x in both cases, except in macro the power is going down by 3x. The 3x and 4x comparison is for pico and macro versus discrete solutions. That’s really quite an important achievement to have that consolidation of basestations on a chip.

OK so wrapping up, any other achievements of Power.org?

BEHMANN: If you have watched the news lately, you probably know that in terms of high-performance computing, two of the Top 10 and five of the Top 20 most powerful computers are based on Power Architecture. Included in these are the BlueGene/Q and also the BlueWater, which will be installed next year.

The Blue Gene/Q [supercomputer] is characterized by a 16-core chip and high performance and high efficiency. And it is about to reach 20 petaflops, so that’s really a great milestone. It was also ranked No. 1 from an energy management perspective [by Green500]. [Editor’s note: Blue Gene/Q was also ranked No. 1 on the list of the world’s fastest supercomputers for six years in a row (see www.top500.org)]. It uses Power7, which has policy-based energy management capabilities.

What does the road map for Blue Gene look like, then?

BEHMANN: We have gone from 596 teraflops in 2004 [with Blue Gene/L] to 1 petaflop in 2008 with Blue Gene/P. And now with Blue Gene/Q, as I mentioned, we are reaching 20 petaflops. So we feel that Power.org has great potential for even more differentiation.

Fawzi Behmann is Director of Marketing and Strategic Advisor for Power.org.

Power.org 512-733-2418 www.power.org

]]> http://tech.opensystemsmedia.com/android/2011/07/power-org-keeps-the-wheels-turning-and-evolution-churning-on-everything-power-architecture-qa-with-fawzi-behmann-director-of-marketing-and-strategic-advisor-at-power-org/feed/ 0 http://tech.opensystemsmedia.com/android/2011/06/android-autosar-at-embedded-world-2011/ http://tech.opensystemsmedia.com/android/2011/06/android-autosar-at-embedded-world-2011/#comments Fri, 03 Jun 2011 16:04:59 +0000 sysgoag http://gdata.youtube.com/feeds/api/playlists/3A8D6640A842B867/D47921B45AEF1FE7 AUTOSAR platform COQOS running concurrently with Android based multi-media applications on top of PikeOS on a single hardware platform:
- real-time capable
- short boot time
- secure separation kernel
- Safe separation of Linux and AUTOSAR