Software architects designing critical embedded systems have tough choices to make when selecting an operating system. Decisions can be both simplified and complicated with new framework and platform initiatives coming into being.

Operating systems that control critical embedded systems have many stringent requirements that they must be able to address in order for them to be considered for deployment. There will always be debate about the best operating systems to deploy in critical applications. However, improvements in real-time operating capabilities in Windows and Linux have opened up the door to options in addition to traditional Real-Time Operating Systems (RTOSs).

Requirements to deploy

Most of the requirements to deploy a critical system are based on the real-time response of the system to the processes they monitor and control. The top requirements are related to:

• Memory protection м/span> A misbehaved thread can corrupt the kernel’s own code or internal data structures causing all types of bad behaviors to the system.
• Fault tolerance and high availability м/span> Even the best software has latent bugs. As applications become more complex and perform more functions, the number of bugs in fielded systems continues to rise. System designers must, therefore, plan for failures and employ fault recovery techniques.
• Mandatory vs. discretionary access control м/span> Mandatory access control provides guarantees to the access of a device or file. Discretionary access controls are only as effective as the applications using them, and these applications must be assumed to have bugs in them.
• Guaranteed resource availability: space domain and time domain м/span> A critical process cannot, as a result of malicious or careless execution of another process, run out of memory resources or deadlock due to priority conflicts that block resources.
• Schedulability м/span> Meeting hard deadlines is especially important, and missing a deadline can be a critical fault; the access to system services must be deterministic.
• Interrupt latency м/span> Some interrupts are higher priority and require a faster response time than others; how long it takes to respond is critical.
• Bounded execution times м/span> Just as response time is critical, how long a task takes to execute is also important.
• Priority inversion РA lower task can block a higher priority task; predictably resolving the block is a must.
• Security м/span> Everything is becoming connected, so trusted computing is more important than ever to prevent malicious attacks.

Adding decisions when adding cores

Today’s multicore processors add an additional layer of complexity that can hinder or enhance the capability of a critical embedded system. In many cases, multiple operating systems may be used within the same computing system. These can be in completely isolated physical computing elements or on the same processor subsystem under the management of a software hypervisor that controls the necessary operating systems. For example, an RTOS that is optimized for characteristics such as memory footprint, performance, and real-time capabilities, runs in one partition and/or core. While Linux, with the advantage of industry-standard user interface technology and robust support of IT capabilities over a network, runs on another partition and/or core. Each operating system is chosen for its advantages and they work together to provide a complete operating environment. Much is being done with hypervisor-enabled configurations but we are still in the early years of taking advantage of all that multicore processors and hypervisors have to offer in addressing performance needs of critical embedded systems.

Today’s landscape

The landscape of operating system choices that can address the requirements for real-time critical embedded applications has changed extensively over the past decade. Many of the RTOS choices from years past have disappeared or retreated to very specialized niches.

What was once dominated by more than 30 choices of RTOSs and an occasional UNIX implementation has now boiled down to Wind River VxWorks, Linux (from many distributions), and Microsoft Embedded Windows. Microsoft has closed the gap by adding more real-time functionality to Windows. UNIX was always popular for select applications, and now Linux, with real-time support since release 2.6, has filled the UNIX void.

A look at the VITA technology companies that develop computer boards capable of running an operating system shows that virtually all of them offer Microsoft Embedded Windows, a Linux variant, and VxWorks on nearly all of their new platforms. The Microsoft Embedded Windows usage is driven by the fact that nearly all the hardware vendors now embrace Intel Architecture processors. Linux has earned its status as a solid choice through the efforts of many that added the necessary real-time capability to the operating system. VxWorks holds strong as the most widely supported RTOS across many processors and in applications of all types. While still widely chosen for new projects and widely deployed, Green Hills Software’s Integrity, LynuxWorks’ LynxOS, and QNX’s Netrino are not as frequently mentioned by these board and system suppliers.

Software development platforms

Software development platform strategies are popular with all of the leading operating system suppliers. Software development platforms are an excellent way to accelerate the software design process. A well-supported software development platform brings all of the key elements needed by the software team to design, develop, test, and deploy a critical embedded system.

Windows Embedded comes in several platform configurations suitable for specific applications: Standard, Server, POSReady, Enterprise, Handheld, Compact, Automotive, and Device Manager. Each of these platform packages has software specifically included to address the needs of the intended target applications.

Wind River has a long list of platforms based on VxWorks with new platforms being defined as markets emerge (Figure 1). Wind River platforms exist for automotive devices, consumer devices, industrial devices, medical devices, gateways, network equipment, infotainment, and military equipment.

Linux has many distributions, many of them from suppliers that have bundled platforms for specific applications. The Wind River Intelligent Device Platform is an example of a complete software development environment for jump-starting machine-to-machine (M2M) device development. Based on Wind River Linux, Intelligent Device Platform includes ready-to-use components built exclusively for M2M applications.

Intelligent systems smartly influence critical systems

The term “intelligent systems” has emerged as a common way to describe devices of many types with embedded processors. Since 2011, Microsoft’s Windows Embedded business has been laying the foundation for an entirely new category within the traditional embedded market — solutions known as intelligent systems that can extend enterprise software and cloud services out to everyday devices.

Intel is driving to simplify the deployment of the Internet of Things and to that end, has introduced the Intel Intelligent Systems Framework, a set of interoperable solutions designed to address connecting, managing, and securing devices in a consistent and scalable manner.

The Intelligent Systems Framework enables OEMs to shift their investments from achieving interoperability to unlocking the value of data. Intel defines intelligent systems to be:

• Connected ­м/span> Simplify device connectivity for wireless and wired networks, speeding time-to-market and reducing expense for device manufacturers
• Managed м/span> Deliver pre-integrated and supported management software from best-in-class Independent Software Vendors (ISVs), making it much easier to manage remote connected devices
• Secure м/span> Provide powerful and customizable security capabilities for protecting devices and their data

These intelligent system initiatives by Microsoft and Intel are providing benefit to architects of critical embedded systems in the form of better integration of hardware and software components necessary to develop a larger and more complex system. The suppliers are being asked to look at the “big picture,” from the operating system to the application, ensuring a robust set of software elements that are interoperable and reduce development time.

The changing future of operating system choice

Platforms and frameworks are changing the process of selecting an operating system. The detailed definitions of platforms and frameworks are eliminating many of the important decisions for the system architect to design application-specific devices. To get to market quickly, architects have to look closely at these “bundles.” This frees up the system developer to focus on the end results by eliminating basic decisions on interoperability and integration challenges. In many ways, making an operating system choice is no longer necessary as it will be defined by the platform architectures specified by industry suppliers.

]]> http://tech.opensystemsmedia.com/embedded-software/2013/03/operating-system-developments-impact-critical-systems/feed/ 0 http://www.embedded-computing.com/articles/id/?5948 http://www.embedded-computing.com/articles/id/?5948#comments Tue, 12 Mar 2013 15:00:00 +0000 Arthur Hicken, Parasoft http://tech.opensystemsmedia.com/embedded-software/?guid=e35bd4d3c57663eaf3a89abb5ae7948b

Static analysis is a development testing activity with the potential to go far beyond simply checking code. When used as part of a policy-driven defect prevention strategy, static analysis can drive a software engineering team’s productivity and minimize fiscal, legal, and ethical risks associated with potentially faulty code. The reason more organizations do not realize the benefits of static analysis, however, is that it’s often homogeneously deployed as a tool for “finding bugs.” But the truth is that there are different implementations of static analysis that serve different purposes in the development process. And while it’s a foregone conclusion that software engineers should run static code analysis, the proper implementation of the right technologies is the difference between wasting time and money and reaching new software development heights.

Generally speaking, best practices are platform neutral – that’s why they’re called “best practices.” The subtleties endemic to embedded development notwithstanding, there are known standards for ensuring quality, regardless of platform. Avoiding memory leaks, for example, should be universal. Further, the relationship between static analysis and software isn’t necessarily defined by the application: It is defined by the purpose of the device. That said, running static analysis is a particularly important best practice for embedded software development.

Traditionally, embedded software is very costly and painful to access post-release. For this reason, most quality or validation activities are focused on eliminating the need to patch or refactor embedded code. Fixing errors post-release poses the greatest risk not only to the brand but also the bottom line. In some industries, particularly in the safety-critical realm, the consequences associated with software defects are so substantial that quality and verification tasks must be executed flawlessly. Software embedded into critical devices such as insulin pumps, weapon control systems, automotive braking systems, and so on, require a preventive strategy that uses a full range of static analysis capabilities; otherwise consequences could include costly litigation, C-level resignations, and even loss of life. This is opposed to agile, continuous development, Web-driven software applications such as smartphones, televisions, and so on, for which a preventive strategy is less important. To this end, the following discussion takes place on the preventive strategy side of the software development spectrum, examining various static analysis implementations:

• Integration-time static analysis
• Continuous Integration-Time (CI) static analysis
• Metrics analysis
• Edit-time static analysis
• Runtime static analysis

Integration-time static analysis

Running static analysis during integration to detect low-hanging fruit and egregious errors is a good starting point for implementing a preventive strategy. Integration-time static analysis simulates feasible application paths without actually executing the code, which is very helpful for systems in which runtime analysis isn’t possible. Static analysis can test across multiple functions and files and catch common memory problems, such as uninitialized memory, overflows, null pointers, and so on.

Static analysis serves a few purposes in terms of the development strategy when organizations begin with testing during integration. First, engineers can review the test results and determine how important they are for the particular application. Static analysis might uncover potential defects that might have a serious impact on software security, reliability, or performance. On the other hand, it could return things that the business might not care about. For example, business probably doesn’t care about a defect in a gaming console that causes the software to crash when an unlikely sequence of operations occurs. The user can simply reboot and continue enjoying their system. Resolving the same sort of issue in other contexts, however, might be crucial to preventing catastrophic consequences.

Static analysis can also help software engineers find potential defects that would have been very difficult to conceive of during the risk assessment phase. Engineers can catalog potential defects to improve future risk assessment iterations.

Continuous Integration-Time (CI) static analysis

After running integration-time static analysis, software engineers should have a stronger sense of potential systemic problems in the code. The next step is to run CI static analysis to enforce the coding policy outlined in the planning phase. This prevents the types of defects discovered during integration-time analysis.

For every issue discovered in static analysis, there are at least 10 more of the exact same thing in other places in the code. Static analysis is the ideal tool for addressing all violations of the same kind at the same time. This is opposed to chasing every possible path through the code. It’s far better to find the systemic problems in order to create an environment in which bugs cannot survive.

When we talk about static analysis, in many cases we mean anti-pattern analysis. A positive pattern is something that should be in the code. For example, a policy that requires engineers to use a typedef when declaring function pointers is a positive pattern static analysis rule[1]. This is in contrast to a policy that, for example, prohibits the use of the data() member function from a string class when interfacing with the standard C library[2].

Executing both types (positive- and anti-pattern) of static analysis is important, but it’s worth mentioning this distinction because if the organization spends the time to build a coding policy based on positive patterns, this ensures that software engineers are building code exactly how it should be per business objectives or compliance requirements.

Metrics analysis

Metrics analysis is a static analysis implementation that evaluates code characteristics and provides insight about the code that can help software engineers identify weaknesses (Figure 1). It is a critical sensor that can highlight areas of the application that can be prone to logical errors. Metrics analysis is an essential baseline measurement that should trigger further analysis, such as code review or some other remediation activity.

Metrics analysis is best used as early as possible because it might affect how software engineers write their code. Avoid trying to implement metrics analysis reactively or during the QA phase. The goal with metrics analysis isn’t just to detect potential defects; it’s to detect them in such a way that allows engineers to follow a sustainable coding trajectory. Run metrics analysis on potential defect hotspots, remediate any violations, and implement a pattern-based analysis rule to prevent future occurrences.

Any metric that correlates to potential problems is fair game. For example, a medical device company might use metrics analysis to measure cyclomatic complexity because a high score indicates that there are too many decision points for the device to handle during normal operation. Knowing that the complexity score exceeds the threshold set in the coding policy when there are 10 branches to cut, as opposed to finding out in the QA phase, will help keep the project on time and on budget. The organization might, for example, want to measure public variables because a high number might correlate to too many dependencies in the code. Each organization will need to decide which metrics can be correlated to possible defects in the code.

Edit-time static analysis

The static analysis sweet spot is while the developer is working in the editor. Running static analysis at edit time serves a few purposes. First, it points software engineers to potential problems. Second, it implements the risk assessment strategy by ensuring that any issues are remediated systemically.

But when should static analysis be implemented? We’ve discussed why implementing static analysis too late is a problem; however, it can also be implemented too early because there must be enough context for static analysis to provide meaningful information. Running static analysis on a character, line, or even statement creates too much noise to be useful. Enforcing positive design patterns ensures that new code is built as intended – while it’s being written. Running static analysis at edit time is a powerful way to promote the correct behaviors within the development team because feedback is rapid and in context of the code being written. Leveraging this type of analysis makes code reviews more productive because engineers should be able to correct policy-based errors immediately.

Runtime static analysis

Some static analysis patterns can detect defects at runtime. If the embedded target can accommodate the overhead, the organization should execute runtime static analysis to round out its preventive strategy. Runtime static analysis detects errors while the code is actually running, which enables software engineers to test real paths with real data.

Final note about static analysis and QA

In an ideal preventive strategy, errors found when QA runs static analysis should already be known and determined acceptable. This is because software engineers should have already tested against and adjusted design patterns to enforce coding policies. Violations at this stage mean that there is a problem with the process, such as improper static analysis rules. In these cases, QA needs to send the code back to development so they can find the systemic cause of the defect and implement a rule to prevent future occurrences. From this perspective, static analysis is a much better quality gate than a bug finder.

References

[1] Joint Strike Fighter, Air Vehicle, C++ Coding Standards, chapter 4.22 “Pointers & References”; AV Rule 176

[2] PCI Data Security Standard Version 1.2; “Requirement 6: Develop and maintain secure systems and applications”

Arthur Hicken is Evangelist at Parasoft and can be contacted at Arthur.Hicken@parasoft.com.

Wayne Ariola is VP of Strategy at Parasoft and can be contacted at Wayne.Ariola@parasoft.com.

Adam Trujillo is Technical Writer at Parasoft and can be contacted at Adam.Trujillo@parasoft.com.

Parasoft info@parasoft.com www.parasoft.com

Follow: Twitter Blog Facebook LinkedIn YouTube

]]> http://tech.opensystemsmedia.com/embedded-software/2013/03/getting-down-to-business-leveraging-the-right-static-analysis/feed/ 0 http://www.embedded-computing.com/articles/id/?5946 http://www.embedded-computing.com/articles/id/?5946#comments Tue, 12 Mar 2013 15:00:00 +0000 Jon Jarboe, Coverity http://tech.opensystemsmedia.com/embedded-software/?guid=8c9163b3bbadeefeb3317c13550e148d

When it comes to software development, the old adage is best spun in a slightly different way: better “early” than never. Accordingly, static analysis can help those developing in Java to stay one step ahead of potential coding problems.

Today’s software development teams are under immense pressure; the market demands high-quality, secure releases at a constantly increasing pace while security threats become more and more sophisticated. Considering the high cost of product failures and security breaches, it is more important than ever to address these risks throughout the software development process. Potential problems need to be spotted early to prevent release delays or, worse, post-release failures.

Fortunately, there are numerous tools to help developers manage these risks, helping to identify potential problems early in the development phase when issues are less disruptive and easier to fix. They are readily accessible to developers and easy to use within many development environments. This applies to developers programming in any language; however, we focus on Java in this discussion (see Sidebar 1).

Static analysis helps mitigate risk

When considering static analysis tools for Java or otherwise, it is important to understand what these tools are. The term “static analysis” refers to the approach of analyzing a program without executing it. As we’ll see in the next section, static analysis tools can be used to produce reports on anything from coding standard violations to specific errors or vulnerabilities. Simply put, static analysis tools analyze source code to find information useful for managing risk.

One benefit of static analysis is that it can be performed early in the development cycle, often before the application will even execute. It is commonly integrated into an automated build, so that there is virtually no overhead to running frequent analyses. By integrating static analysis into the inner development loop, users maximize the value they get from such tools.

When used in conjunction with a well-designed development process, static analysis tools provide crucial visibility into the state of the software. This enables development teams to understand the level of risk in their code and where the risk resides so they can take action to mitigate or remove it entirely (Table 1). Individual tools generally focus on specific problems faced by software development teams, and teams often use a combination of these tools to get a comprehensive view of their development effort.

Developers have traditionally used static analysis tools via a simple IDE integration or as stand-alone tools. While the tools add significant value to the development effort, the proliferation of tools has created efficiency problems as developers spend more and more time using and maintaining different tools and sifting through more and more results. To wisely manage development resources, teams must be able to effectively manage, filter, and prioritize all those issues.

To address these problems, development testing platforms have emerged to unify and manage all of this static analysis information in one place, simplifying the user experience and increasing visibility and efficiency at larger scales while providing relevant access controls and reporting. Development testing platforms are even starting to blur the line between static analysis and other types of analysis by utilizing – during the static analysis process – artifacts generated during earlier program runs. For example, these platforms can use code coverage information from test runs during static analysis to effectively identify missing test cases automatically. The traditional approach to this problem requires significant manual effort based on simple coverage thresholds. By leveraging data from different sources, these platforms are able to significantly reduce the manual effort and time required to accomplish this with other methods.

Selecting static analysis tools for Java

The most popular, free, static analysis tools for Java are probably Checkstyle, PMD, and FindBugs. While they all fall under the “static analysis” umbrella, their strengths are so sufficiently different that many consider the tools to be complementary rather than alternatives.

Checkstyle

Checkstyle is billed as “a development tool to help programmers write Java code that adheres to a coding standard[1],” although it does not strictly limit itself to coding standard enforcement. It provides a documented API for users to define their own custom checks. Typical coding standards utilize basic rules to make code more readable and reduce the likelihood that future code changes will introduce bugs. Standards tend to define conventions about formatting (white space, bracketing, naming, commenting, and so on), inheritance, and visibility. When adequately enforced, well-designed coding standards can help developers reduce risk. Enforcement can be difficult, though, since coding standards generate a lot of violations and there can be significant pressure to ignore noisy rules. With legacy code, this can make enforcing new coding standards unfeasible. While most of the issues identified by Checkstyle do not affect code correctness, robustness, or performance, there is real value in helping developers quickly understand code written by others. It is not always obvious how to quantify the risk represented by these violations and it is problematic to measure risk directly from violation counts, but changes in those counts can be a reasonable proxy for changes in risk.

PMD

PMD is described as “…a source code analyzer. It finds unused variables, empty catch blocks, unnecessary object creation, and so forth[2].” It, too, is evolving and the current checks focus mainly on syntactic oddities that might belie developer mistakes, such as overcomplicated expressions, empty blocks, unused variables, parameters, and class members. It also has a popular module to identify duplicated code. Because it is generally reporting “suspicious code” as opposed to specific coding errors or standards violations, the user will need to carefully select the checks enabled for everyday use. Because enforced rules are selected by the user, this tool can be useful for both legacy and greenfield projects, and it is often easy to correlate these counts with risk. Unfortunately, it might not be obvious whether reported issues should be considered defects or maintenance concerns.

FindBugs

FindBugs is probably the most popular of these tools. It looks for actual bugs in the code, as well as suspicious code and standards violations. Because of the wide range of reported issues, it is important to use a configuration that includes the most relevant checks for the project. This is especially true for legacy projects, as it’s easier to keep new projects clean from the beginning. Like PMD, any team can benefit from using FindBugs and associating issue counts to risk can be straightforward.

Commercial static analysis tools show similar diversity, identifying everything from standards violations to actual defects and security vulnerabilities. To illustrate how a commercial tool might compare to a free tool, I analyzed version 1.496 of the Jenkins job management system (www.jenkins-ci.org) using a proprietary static analysis solution and version 2.0.1 of FindBugs, with all checks enabled. On this code base, 852 unique issues were identified – with only 28 issues identified by both products. The proprietary solution found 197 unique issues, with 188 of those coming from high-impact categories (security and concurrency bugs, resource leaks, and unhandled exceptions like null dereferences). FindBugs found 627 unique issues, with 29 coming from those high-impact categories. In short, each of the tools found significant high-impact issues missed by the others, so using a proprietary solution or FindBugs alone will leave significant risk undetected.

Development testing – Tying it all together

Static analysis tools are a powerful ally in the software development effort for Java developers, as these tools enable developers to gain insight into risk throughout the software development life cycle. They are typically easy to automate, enabling users to spend their time fixing problems rather than running the tools.

When it comes to managing risk, more information is generally better – as long as that information illuminates actual sources of risk that developers care about. When deciding which tools to adopt, remember to consider not just the types of issues that analysis tools identify, but how those tools can work together to provide additional value. Also, be sure to configure them appropriately so that the number of issues doesn’t overwhelm your users.

Modern development testing platforms take testing tools to another level by unifying the data in one place, simplifying the user experience, and creating opportunities to provide even more value.

References

[1] http://checkstyle.sourceforge.net/

[2] http://pmd.sourceforge.net/

Jon Jarboe is Senior Technical Manager for Coverity, where he helps developers understand the value of adopting development testing and managing risk throughout the software development life cycle.

Coverity info@coverity.com www.coverity.com

Follow: Twitter Blog Facebook Google+ LinkedIn YouTube

]]> http://tech.opensystemsmedia.com/embedded-software/2013/03/static-analysis-helps-manage-risk-in-java/feed/ 0 http://www.mil-embedded.com/articles/id/?5964 http://www.mil-embedded.com/articles/id/?5964#comments Tue, 12 Mar 2013 15:00:00 +0000 Tim King, DDC-I http://tech.opensystemsmedia.com/embedded-software/?guid=75538ed47870a49af74aecef67e73890

Cache partitioning reduces worst-case execution time for critical tasks, thereby enhancing CPU utilization, especially for multicore applications.

One of the biggest challenges facing developers of certifiable, safety-critical software applications for MultiCore Processors (MCPs) is managing access to shared resources such as cache. MCPs significantly increase cache contention, causing Worst-Case Execution Times (WCETs) to exceed Average-Case Execution Times (ACETs) by 100 percent or more. Because safety-critical developers must budget for WCETs, tasks on average (critical and noncritical) are allocated more time than they need, resulting in significantly degraded CPU utilization. One way to address this problem is to utilize an RTOS that supports cache partitioning, which enables developers to bound and control interference patterns in a way that alleviates contention and reduces WCETs, thereby maximizing available CPU bandwidth without compromising safety criticality.

Cache contention

In a simple dual-core processor configuration (Figure 1), each core has its own CPU and L1 cache. Both cores share an L2 cache. (Note that shared memory and optional L3 are not shown.)

In this configuration, applications executing on Core 0 compete for the entire L2 cache with applications executing on Core 1. (Note that applications on the same core also compete with one another for L2; cache partitioning applies in this case as well.) If application A on Core 0 uses data that maps to the same cache line(s) as application B on Core 1, then a collision occurs.

For example, suppose A’s data resides in L2; any accesses to that data will take very few processor cycles. But suppose B accesses data that happens to map to the same L2 cache line as A’s data. At that point, A’s data must be evicted from L2 (including a potential “write-back” to RAM), and B’s data must be brought into cache from RAM. The time required to handle this collision is typically charged to B. Then, suppose A accesses its data again. Since that data is no longer in L2 (B’s data is in its place), B’s data must be evicted from L2 (including a potential “write-back” to RAM), and A’s data must be brought back into cache from RAM. The time required to handle this collision is typically charged to A.

Most times, A and B will encounter such collisions infrequently. In those cases, their respective execution times can be considered as “average case” (ACET). However, on occasion, their data accesses will collide at a high frequency. In these cases, their respective execution times must be considered as “worst case” (WCET).

When developing certifiable, safety-critical software, one must budget an application’s execution time for worst-case behavior. Such software must have adequate time budget to complete its intended function every time it executes, lest it cause an unsafe failure condition. The safety-critical RTOS must enforce time partitioning, such that each application has a fixed amount of CPU time budget to execute.

With the potential for multiple applications on multiple cores to generate contention for L2 cache, WCETs on MCPs often are considerably higher than ACETs. And since certifiable, safety-critical applications must have time budgets to accommodate their WCETs, this situation leads to a great deal of budgeted but unused time, resulting in significantly degraded CPU utilization.

Cache partitioning

Cache partitioning increases CPU utilization by reducing WCETs, thereby reducing the amount of time that must be budgeted to accommodate WCETs. Again, in a simple dual-core processor configuration (Figure 2), each core has its own CPU and L1 cache and both cores share an L2 cache.

In this configuration, the RTOS partitions the L2 cache such that each core has its own segment of L2, meaning that data used by applications on Core 0 will only be cached in Core 0’s L2 partition. Similarly, data used by applications on Core 1 will only be cached in Core 1’s L2 partition. This partitioning eliminates the possibility of applications on different cores interfering with one another via L2 collisions. Without such interference, the deltas between application WCETs and ACETs often are often considerably lower than is the case without cache partitioning. By bounding and controlling these interference patterns, cache partitioning makes application execution times more deterministic and enables developers to budget execution time more tightly, thereby keeping processor utilization high.

Test environment and applications

To demonstrate the benefits of cache partitioning, DDC-I used Deos (its certifiable, safety-critical, time- and space-partitioned RTOS) to run a suite of four memory-intensive test applications, all with a range of data/code sizes, sequential and random access strategies, and various working set sizes:

• Read only
• Write only
• Copy
• Code execution

The tests were performed on a 1.6 GHz Atom processor (x86) with 32 KB of L1 data cache, 24 KB of L1 instruction cache, and a 512 KB unified L2 cache. Note that while a single-core x86 processor was used for these tests, Deos’ cache partitioning capability applies equally well to applications executing on the same core (which also compete for L2). Further, it does not depend on any features that are special or unique to x86 processors and applies equally well to other processor types (such as ARM or PowerPC).

The tests were run with and without a “cache trasher” application, which evicts test application data/code from L2 and “dirties” L2 with its own data/code. In effect, the cache trasher puts L2 into a worst-case state from a test application’s perspective. That is, the cache trasher mimics real-world scenarios, where different applications run concurrently and compete for the shared L2 cache.

Each test application was executed under three scenarios. In scenario 1, which is conducted without cache partitioning or cache trashing, the test application competes for the entire 512 KB L2 cache along with the RTOS kernel and a variety of debug tools. This test establishes baseline average performance, wherein each test executes with an “average” amount of L2 contention.

In scenario 2, which uses no cache partitioning, the test application competes for the entire 512 KB L2 cache along with the RTOS kernel, the same set of debug tools used in scenario 1, and a rogue cache trasher application. This test establishes baseline worst-case performance, wherein each test executes with a worst-case amount of L2 interference from other applications, primarily the cache trasher.

In scenario 3, which uses cache partitioning and cache trashing, three L2 partitions are created:

• A 256 KB partition allocated to the test application
• A 64 KB partition allocated to the RTOS kernel and the same set of debug tools used in scenarios 1 and 2
• A 192 KB partition allocated to the rogue cache trasher application.

This scenario establishes optimized worst-case performance, wherein each test executes within its own L2 partition with no interference from other applications, including the cache trasher.

Cache partitioning results, benefits

Figure 3 shows the results for the read-only test application.

For example, with no cache partitioning and no cache trashing (scenario 1, ACET), the read-only test averaged 105 microseconds per execution given a working set size of 512 KB. In scenario 2 (WCET with no partitioning, cache trashing added), the test averaged 400 microseconds per execution for the same 512 KB working set, a 280 percent increase. When cache partitioning is added (scenario 3, WCET with cache trashing), the average execution time drops to 117 microseconds, or just 11 percent higher than the ACET.

These results demonstrate the efficacy of cache partitioning for an application that performs a large number of reads per period. Though difficult to discern here due to differences in magnitude, the impact on bounding WCETs is more pronounced when the application’s working set size fits within the cache partition that it’s using (in this case, 256 KB). This result is expected because of the nature of cache. That said, embedded, real-time applications tend to have relatively small working set sizes, so we expect that cache partitioning will benefit most applications.

Results for the write-only test were similar to the read-only test, though more pronounced for smaller working sets. For larger working sets, results showed relatively small differences between WCETs with and without cache partitioning.

Results for the copy test were similar to the read-only test, though more pronounced for smaller working sets. For larger working sets, results were less dramatic, but still showed significant improvement (roughly 2x) in WCETs with cache partitioning.

Results for the code execution tests were similar to the read-only test, though somewhat less dramatic.

Note that it is possible for applications executing in the same cache partition to interfere with each other. However, such interference typically is much easier to analyze and bound than the unpredictable interference patterns that may occur between applications executing on different cores with shared cache. In those situations, if interference is unpredictable, then applications could be mapped to separate cache partitions.

The benchmark results clearly demonstrate that cache partitioning provides an effective means of bounding and controlling interference patterns in shared cache on an MCP. In particular, WCETs can be bounded and controlled much more tightly when the cache is partitioned. This allows application developers to set relatively tight, yet safe, execution time budgets, thereby maximizing MCP utilization.

Of course, results will vary for different applications and hardware configurations, and additional RTOS capabilities will be required to successfully certify safety-critical MCP-based systems. Regardless, these results represent a significant advancement toward the goal of using MCPs to host certifiable, safety-critical applications.

Tim King is the Technical Marketing Manager at DDC-I. He has more than 20 years of experience developing, certifying, and marketing commercial avionics software and RTOSs. Tim is a graduate of the University of Iowa and Arizona State University, where he earned master’s degrees in Computer Science and Business Administration, respectively. He can be contacted at tking@ddci.com.

DDC-I 602-275-7172 www.ddci.com

]]> http://tech.opensystemsmedia.com/embedded-software/2013/03/cache-partitioning-increases-cpu-utilization-for-safety-critical-multicore-applications/feed/ 0 http://www.mil-embedded.com/articles/id/?5962 http://www.mil-embedded.com/articles/id/?5962#comments Tue, 12 Mar 2013 15:00:00 +0000 John McHale, Editorial Director http://tech.opensystemsmedia.com/embedded-software/?guid=0afecfa39ffc289ac963a2a5b78194ec

The task of improving situational awareness for military pilots in a tough budget climate with little development funding available requires designers to use open architectures and common standards to keep costs down. This trend also has fueled the enthusiasm behind the FACE Consortium, which promises long-term potential savings of billions of dollars by enabling software reuse across multiple avionics platforms.

Department of Defense (DoD) leaders want their pilots to have the best technology possible to do their jobs – whether it is a new touch-screen primary flight display, night vision goggles, 3D flight simulation systems, or even a brand-new aircraft to replace a decades-old platform. However, today’s economic climate will not allow for new fighter jets or helicopters, so military program managers need to compromise and find ways to keep older aircraft platforms flying while still enhancing capability for the pilot.

“Military avionics customers in fixed- and rotary-wing platforms want improved situational awareness and to increase their mission envelope and effectiveness,” says Karl Shepherd, Marketing Director for Airborne Solutions at Rockwell Collins in Cedar Rapids, IA. “For the DoD it is all about designing avionics that can reduce the workload of a pilot so they can enhance their decision making during missions. It’s about helping pilots make decisions instead of taking decision making away from them.”

While these enhancements do not require an entire new aircraft, the necessary upgrades can still be quite expensive – not just the up-front costs of new components and systems, but the behind-the-scenes costs such as training and maintenance. Keeping avionics retrofit costs down requires a move toward more commonality and open architecture designs.

Open architectures

“Open architectures provide the military customer with more value for his dollar,” says Robert Waage, Director of Business Development at Elbit Systems of America in Fort Worth, TX. Multiple vendors can be used within one program, which helps drive costs down and enables platforms to fly for decades, he adds. Elbit’s redesign and upgrade of the Apache Block III AH-64D Mission Processor will use an open architecture to accommodate new capabilities as they become available, Waage continues. The Army Apache team wants to sustain and maintain these aircraft until 2040, so they and the Apache prime contractor – Boeing – are creating road maps for future refreshes that leverage open architectures to achieve that goal, he adds. “It is about having market agility and flexibility.”

“There is an increasing requirement that solutions should be based on open, interoperable, industry standards – even though the underlying technology is often less important to military integrators,” says Simon Collins, Product Manager, GE Intelligent Platforms in Huntsville, AL. “Customers are more focused on how the solution meets their functional needs and how they will bring that solution to deployment.”

Leveraging commercial avionics systems for military platforms

Looking to add avionics functionality and capability in an affordable way, military program managers often will look to adapt designs and applications that gained traction first in commercial aircraft cockpits.

“Designing with open architectures when upgrading military avionics platforms is crucial if we want to be able to leverage commercial processors and other components without major obsolescence issues,” Shepherd says. “At Rockwell Collins we have been doing this for more than 10 years using technology developed for commercial avionics and then adapting it for military platforms. A big example of this is our Pro Line Fusion Synthetic Vision (SV) capability – developed for the business jet community and now being adapted for use in military rotary wing applications under a DARPA contract. The work essentially has a synthetic avionics backbone that hosts the SV terrain engine and fusion algorithms. The fusion algorithms process the data coming from the multifunction radar sensor along with terrain and obstacle data to provide an integrated 3D view of the operational environment on Heads-Down Displays and Heads-Up Displays in the cockpit. Real-time sensor imagery can be overlaid as well. The sensors provide real-time imagery, fused with the SV database imagery to give the pilot increased awareness when he can’t see out the window.

“A primary difference between military and commercial SV applications occurs with the military platform’s mission parameters,” Shepherd continues. “We started with a civil-certified version of SV and made the necessary changes for high-resolution terrain data in a 3D environment out-the-window type of display. The initial rotary wing helicopters making use of SV technology will be those experiencing brownout conditions in Iraq and Afghanistan such as U.S. Army MH-60 Black Hawk and MH-47 Chinook helicopters. We see the Marine Corps and Army likely integrating the SV systems into more platforms further down the road.”

High TRLs wanted

A tight budget environment may be perceived as one fostering increased use of more affordable COTS equipment since there is little funding available for development, but COTS has different meanings for different people. Some view it as too commercial and therefore lacking in reliability, while others feel that view is outdated and COTS has a proven performance track record. However, there is no proven metric for measuring the reliability of avionics products tagged as COTS, since it is more of a procurement term than a technological one. Instead, military program managers and integrators are turning toward Technology Readiness Levels (TRLs) to determine an avionics product’s pedigree for military systems – whether it is COTS or not. “The generals are demanding a high TRL level; therefore, I want and demand a high TRL level – something that has a high proven operational capability such as TRL level 7 or higher,” Elbit’s Waage says.

The FACE revolution

Open architectures, common industry standards, and TRL requirements have all been elements of an avionics procurement evolution driven by a need to better manage development costs without sacrificing capability and innovation. Avionics upgrades have embraced these concepts and seen major cost savings that enabled older platforms to live on for decades. Now branches within the DoD are taking cost-effectiveness to another level entirely by requiring future avionics systems to ensure portability of software across multiple platforms. This initiative has taken form as the Future Airborne Capability Environment (FACE) Consortium, and support for it is growing rapidly as DoD officials look for ways to make the funding cuts their civilian leadership is demanding.

“We see FACE – which is an open systems approach for avionics – as a natural evolution of leveraging commercial technology and common standards,” Shepherd says. “It focuses on the reuse of software applications from one aircraft to another – even from one military service to another. Instead of paying each OEM or contractor every time you develop a software component, you can develop once and then redeploy the software.”

“There is quite a bit of activity happening within the FACE Consortium today,” says Chip Downing, Senior Director, Business Development, Aerospace & Defense at Wind River Systems in Alameda, CA. “The membership now has more than 50 organizations – including essentially every major U.S. defense prime contractor. The completion of the Technical Standard for Future Airborne Capability Environment (FACE), Edition 2.0 is expected [this month] in March 2013. The FACE Conformance Test Policy, Conformance Certification Guide, Conformance Tests, and the Conformance Verification Matrix Guides should be completed [later this month] with the official release targeted for early Q2 2013. Two major programs have also been awarded requiring FACE compliance to date.”

One of these programs is the modernization of the C130-T, awarded to Lockheed Martin Mission Systems & Training in Owego, NY, by the U.S. Naval Air Systems Command. Under the $30 million contract, Lockheed Martin engineers “will deliver a suite of GFE [Government-Furnished Equipment] and CFE [Contractor-Furnished Equipment] to provide new navigation, communication, flight management, and controls and displays capability,” says John Aebli, Director of Avionics Products for Lockheed Martin’s Mission Systems & Training business.

“The new avionics package is built around the latest generation of FACE-conformant Lockheed Martin avionics,” he continues. “The FACE framework enables cost savings by isolating change and variability. More specifically, individual software applications are isolated from the aircraft-specific configurations for controls and displays, other avionics, aircraft systems, and the hardware platform. This isolation enables software migration from platform to platform, as well as third-party application development, which leverages the nonproprietary software interfaces.” Lockheed Martin engineers also will develop and deliver nine initial cockpit kits for the C130-T upgrade.

Enthusiasm for a new standard

“Whenever you talk to military leaders about FACE, they initially react as if the last thing the U.S. military needs is a new standard, and their defense shields go up,” Downing says. “But once they learn how much money can be saved over the long-term, and how much [more] efficient and capable their platforms will be with FACE adoption, they can’t hide their enthusiasm. FACE will potentially save the government billions of dollars in the long run. FACE has created both technical and business guidelines, and combined, both will drive more capability to the warfighter faster. Because the FACE team is getting so many work products completed, everyone can see the results, and this has energized the entire team.”

“It’s really vital for us to be members of FACE,” GE IP’s Collins says. “We see it as an incredibly important organization with objectives that are hugely significant for the industry in terms of application development, portability, reuse, and compliance, together with the inherent time- and cost-advantages of COTS solutions. When it comes to FACE, the customers we’ve been talking to typically fall into two camps: ones who are totally committed to going down the FACE-compliant route in their development and customers who see the benefits that FACE will bring but for now are watching and waiting.”

Interoperability

“The movement behind FACE basically came from the government and DoD being fed up with being charged every time they used software programs in different platforms,” says Robert Day, Vice President of Marketing for LynuxWorks in San Jose, CA. “FACE solves this problem by creating interoperability among software platforms. Applications that have the common FACE API can move among multiple platforms, making it easier to keep legacy products and have them work with new applications and designs.”

“Interoperability is an underlying theme with FACE. Software applications running on a mission computer in a helicopter platform could be reused on an Unmanned Aerial Vehicle (UAV), or the UAV system could work on a manned aircraft – all because of the common foundation,” Downing says. “In this way, FACE has a similar utilization model to that of Android, where applications can be used across multiple platforms due to its underpinning architecture.

“The FACE team was smart – they optimized existing standards, ARINC 653, and POSIX to create the FACE technical standard,” Downing continues. “Realizing that there is a broad range of applications in military avionics, the team created four separate profiles – Security, Minimum Safety, Extended Safety, and General Purpose. The Security and Safety profiles are designed to complement Common Criteria security and RTCA DO-178C safety certification environments. I expect that all of these profiles will be able to leverage the existing COTS certification and quality attributes of existing ARINC 653 and POSIX products from a wide range of vendors.” Wind River’s VxWorks 653 Real-Time-Operating-System (RTOS) for ARINC 653 time-and-space partitioned environments is FACE compliant, he adds.

“Most of the avionics funding for the next few years will go toward upgrading and modernizing current platforms,” Day says. “If you don’t have a FACE API, you likely will be left out of new refresh programs coming up. Our safety-critical RTOS 178 product – which has a native POSIX API – is FACE compliant.”

“We have been reflecting FACE activities in our product development road map and are working with a number of software vendors to ensure their offering is compatible with the FACEREF1 Software Reference Platform that we introduced last year,” Collins says. “It’s a platform that features GE IP’s SBC312 3U VPX single board computer and PMCCG1 graphics PMC” and enables organizations developing FACE-compliant applications to reduce risk by using preconfigured, prevalidated, and pretested COTS solutions, he adds.

Green Hills Software in Santa Barbara, CA, which makes the POSIX-compliant INTEGRTY RTOS, also is a member of FACE. The INTEGRITY-178B tuMP multicore operating system was selected for use in their Gen II Mission Computer for upgrades of the U.S. Marine Corps UH-1Y and AH-1Z helicopters.

]]> http://tech.opensystemsmedia.com/embedded-software/2013/03/military-avionics-designs-embrace-common-standards-and-trls/feed/ 0 http://www.mil-embedded.com/articles/id/?5931 http://www.mil-embedded.com/articles/id/?5931#comments Mon, 11 Feb 2013 15:00:00 +0000 John McHale, Editorial Director http://tech.opensystemsmedia.com/embedded-software/?guid=0134f2064dd339877ad05509b05d409a

Radar and Electronic Warfare (EW) designers’ thirst for more and more data is driving innovation at the signal processing level as embedded computing suppliers work magic with FPGAs and processors to create intelligent, fast sensor networks.

The need to know where and when the enemy will strike is no less important today than when the allies cracked the allegedly unbreakable German Enigma code during World War II. The only difference today is the sophistication of the technology on either side. Modern Electronic Warfare (EW) systems can detect, collect, and catalog just about every signal, while radar systems being developed today will be able to track dismounted personnel, small objects at sea, as well as enemy fighters. To make these capabilities possible, embedded computing wizards are packing as much processing power as possible at the payload level on the platform, right next to the sensor. They mix together components such as GPGPUs, multicore processors, FPGAs, and complex software algorithms in different configurations designed to meet the low Size, Weight, and Power (SWaP) requirements demanded by their military customers.

Sensor technology and the need for greater bandwidth are driving military electronics designs, especially in radar and electronic warfare applications, says Ray Alderman, Executive Director of VITA. “What the processor and sensor technology enables us to do is absolutely incredible. Every aircraft has a signature. When we hit an enemy aircraft with radar we can figure out where it came from, destroy that location, then figure out where it is going and eliminate that destination as well. The only problem with increasing bandwidth on the sensors is the ability to stream data over the RF links is still poor. Therefore, the focus going forward is to move the processor next to the sensor.”

“Department of Defense (DoD)-oriented customers want to be able to perform data exploitation onboard platforms to provide immediate actionable intelligence to the warfighter – avoiding delays and bottlenecks encountered when sending large amounts of data to a ground station,” says Paul Monticciolo, Chief Technology Officer at Mercury Systems in Chelmsford, MA.

“In the past Intelligence, Surveillance, and Reconnaissance (ISR) systems were aimed at finding that particular truck or plane in an area of interest; now they are required to have the capability to pick individuals out of a crowd,” says Vincent Chuffart, Embedded Computing Specialist at Kontron in Poway, CA. “Today’s sensor systems can detect everything, so integrators want to process that sensor data and extract all they can out of it at the sensor level before they transmit it to the warfighter.” Kontron puts a lot into small form factor designs such as 3U VPX to handle the high-speed processing and meet SWaP requirements, he continues. There is a trend toward smaller and cooler systems, especially with the vast majority of upgrades in front of us being just a refresh of existing equipment, Chuffart adds.

“Users are trying to detect and decode complex radar or communication signals so they need more channels and these channels need to be accommodated simultaneously,” says Rodger Hosking, Vice President at Pentek in Upper Saddle River, NJ. “An example would be a communication system that listens to multiple radios or communicates with multiple radios at the same time or a system that requires wider signal bandwidths for radar. Once these signals are digitized, higher data rates are required to move the data, which puts a bigger load on the DSP engine to accommodate the data so it can keep up in real time.” A higher level of system performance is required through more sophisticated signal processing techniques, higher-speed A/D converters to capture wideband signals, and faster FPGAs to do signal processing and process algorithms at higher rates, he adds.

Harnessing commercial processor technology

Embedded computing companies are leveraging commercial processor technology – whether from Intel, NVIDIA, or other companies – to drive the performance of radar and electronic warfare systems. “FPGAs and GPGPUs are excellent for front-end sensor processing, but the SWaP characteristics of multicore processors are enabling us to provide the type of performance and analysis of data that is typically done in a ground station,” Monticciolo says. “Some companies are working with mobile-class processors, but when you start doing massive correlations and graph-type processing, you need the performance of a multicore processor in a server-class solution. This also guarantees code portability – being able to run the same code on a 1U server in the ground station and in a small embedded processing system up on the platform.” Mercury has a high-performance embedded computing solution with their PowerStream technology performing radar processing onboard the Navy’s Aegis-class ships.

“On Intel Architecture, the advent of AVX and the coming of AVX2 with a fused multiply-add pipeline are significantly improving the applicability of Intel devices to signal processing applications, as is the increasing performance of the integrated GPUs,” says Peter Thompson, Senior Business Development Manager for high-performance embedded computing at GE Intelligent Platforms in Huntsville, AL. “Now that NVIDIA is shipping Kepler GPUs, we are seeing significantly better performance per watt than the previous generation Fermi offered. GPUDirect is helping us to reduce sensor-to-processor latency, and opening up some new applications such as EW that are time sensitive. The interconnects are keeping pace too – PCI Express Gen 3, 40 GbE, and 56 Gbps InfiniBand are starting to become available or are already out there, and are allowing us to keep the processing pipelines fed.”

“For many EW and DSP applications, our customers have found that the Intel Core i7 processor provides them with the right balance of performance and SWaP,” says Ben Klam, Vice President of Engineering at Extreme Engineering Solutions (X-ES) in Madison, WI. “The Intel Advanced Vector Extensions (AVX) supported by the Intel Core i7 processor provides excellent DSP performance with support for operations on 256-bit vectors.”

Managing power consumption and signal integrity

Processors do enable amazing applications, but also create serious headaches for embedded system designers with the heat they generate. Cooling the systems and keeping their power consumption low can be quite complex, especially as system designs trend toward smaller form factors.

“Two big challenges faced by embedded signal processing designers are power consumption and signal integrity,” says Denis Smetana, Product Marketing Manager for FPGA products at Curtiss-Wright Controls Defense Solutions in Ashburn, VA. “Devices continue to run faster, which requires more power. With so many high-speed signals, more exotic PWB material needs to be used along with special handling of high-speed traces and more detailed signal integrity and power integrity analysis. The super high-speed signaling is running the processors so fast that a lot of heat is being dissipated and as geometries keep getting smaller, leakage current gets bigger as a percentage of total power. And leakage current is very sensitive to temperature. This results in a significant power increase as temperature rises. Software/firmware also is needed to be able to utilize the larger processing performance.”

“There are some applications with DSP performance requirements that exceed the capability of the Intel Core i7 processor where customers add GPGPUs or FPGAs into the mix, but the cost is high,” Klam explains. “GPGPUs typically consume more power than embedded General Purpose Processors (GPPs), which in turn creates more heat that has to be dissipated. GPGPUs are driven by the consumer market, so product obsolescence can be a big problem for long-life embedded systems. And development is much more complex – software development in the case of GPGPUs and VHDL and software development in the case of FPGAs. We are also seeing a lot of demand for systems that require something smaller than 3U VPX can support,” Klam says. “We have developed a small form factor system, the XPand6000 Series, that utilizes COTS components – COM Express, PMC/XMC, and SSDs – to enable customers to rapidly prototype and deploy small form factor solutions.”

FPGAs and the front end

For the front end of signal processing solutions – where the signals are received by the embedded computing system – designers far and wide sing the praises of today’s FPGAs, whether Xilinx or Altera, for enabling the capabilities of modern radar and electronic warfare platforms.

“We are seeing people wanting to put more components of their radar systems in an FPGA,” says Jeff Milrod, CEO of Bittware in Concord, NH. “Altera’s Stratix technology is supporting this by placing a lot of floating-point capability in the front end. That way the system can aggressively integrate full imaging and even identify areas of interest before it sends data to the ground. FPGAs are needed because the rates are so high, now everybody seems to want direct RF conversion – so they get gigahertz sample rates flying and then handle them in the FPGAs.”

Compared with a GPP, the FPGAs are much better suited for real-time embedded systems. The GPP, while very fast, is not well connected to I/O and does not do real-time data processing as well as an FPGA. Pentek’s Onyx 71720 software radio module is used in radar, UAV, and communication signal processing applications and is based on the Xilinx Virtex-7 FPGA, used in radar and communication signal processing applications.

“FPGAs will continue to dominate digital signal processing for a myriad of reasons: mainly processor technology isolation and control of one’s own IP – the critical element in any real-time, signal processing platform,” says Doug Patterson, Vice President of the Military & Aerospace Sector at Aitech in Chatsworth, CA. Aitech’s military-grade 3U CompactPCI, 3U VPX, 6U VPX, and 6U VMEbus systems leverage FPGAs for radar and fire-control applications.

FPGAs process everything very fast and enable radar/EW integrators to have more control, to adapt and change their applications based on mission results, says Jane Donaldson, President of Annapolis Microsystems, in Annapolis, MD. “A major drawback with FPGAs for many is the expense of programming in VHDL, which adds labor costs and lengthens the design cycle,” she continues. To reduce time to market and development costs on their WILDFIRE FPGA boards, Annapolis engineers use their CoreFire solution to program FPGAs. It enables software programmers working on GPPs to also program FPGAs, Donaldson adds.

“The combination of FPGAs with SBCs, GPGPUs, and multicore processors in one system is how requirements are trending,” Smetana says. “For example, on the front end, FPGAs are well suited for parallel processing of sensor data, but then may feed the data to GPGPUs for additional parallel processing or multicore processors for sequential processing.” Curtiss-Wright is working with Tektronix to improve performance for wideband, low-latency processing for Digital Radio Frequency Memory (DRFM), electronic warfare, signal intelligence, and electronic countermeasure applications. Under the collaboration, Curtiss-Wright’s CHAMP-WB (“Wideband”) board will work with the Tektronix ADC/DAC FMC module, the TADF-4300, to become the CHAMP-WB-DRFM utilizing a Xilinx Virtex-7 FPGA.

FPGAs embracing ARM and OpenCL

“In the future we see embedded systems generally moving toward embracing ARM processor technology,” Milrod says. “There is a huge user community and infrastructure, it is quite efficient, and the performance continues to improve dramatically with 64-bit now emerging. Although currently there is no ARM COTS community in the military, interest in these designs is exploding in the Linux world and could very well catch on in military designs. Both Altera and Xilinx are integrating ARM into all their FPGAs from now on. At BittWare, we’ve started to integrate them onto our high-end VPX boards. The ARM can handle housekeeping functions while the massive bulk processing onboard is handled by the FPGAs and/or floating point coprocessors such as our Anemone many-core processor that is based on Adapteva’s Epiphany architecture.

“One standard that is getting interest in the defense community is the OpenCL framework,” Milrod says. “Altera has made a big push with it and they’ve really driven OpenCL on their FPGA designs. Within the defense community we’ve seen attention for OpenCL because some designers are dissatisfied with inefficiencies of running on GPUs, and then the difficulties they have when porting GPGPUs to FPGAs.”

Software challenges

Managing processors and the heat and power they generate is only part of the difficulty in creating complex signal processing solutions. “Integrating new, untested technologies while developing new, critical application software drains budgets and saps our customers’ resources and energy,” Patterson says. “Serial buses and parallel buses operate very differently, especially when time-critical messages must occur in order and in phase. Multiple serial buses can easily become out of sync and message passing becomes tricky with RTOS overhead to sort out the time sync issues. Command/response buses with tight, time-aware and synchronized higher-level data protocols are critical in real-time process control systems.”

“Radar and EW systems are so complicated with so many levels that one of our biggest challenges lies in offering software board support packages that work with various types of middleware,” Pentek’s Hosking says. “Often the code and middleware don’t interact well and don’t do what people expect them to do. This is the biggest challenge we face – providing tools that enable our customers to efficiently develop their unique and highly complex applications under popular operating systems like Windows, Linux, and VxWorks.”

Software solutions also help radar display processing engineers to combine “graphical data with real-time radar data and to create pictures using standard commercial technology,” says David Johnson, Managing Director for Cambridge Pixel in Royston, England. “The amount of data being processed and displayed is more complex than ever, so to create complex pictures of graphical data, we use high-end graphics chips from companies such as AMD and NVIDIA. We present a representation of the data generated by the front-end processors that makes sense – taking multiple layers of radar data, map data, chart data, and other sensor data fused together in one composite display. The system integrator decides how he wants the ISR information displayed.” Cambridge Pixel’s standard product – the SPx Radar Development Library – is a collection of software modules that can be used for radar displays as well as recording or tracking systems, he adds.

]]> http://tech.opensystemsmedia.com/embedded-software/2013/02/fast-processors-fpgas-fuel-radarew-signal-processing-performance/feed/ 0 http://www.embedded-computing.com/articles/id/?5918 http://www.embedded-computing.com/articles/id/?5918#comments Fri, 08 Feb 2013 15:00:00 +0000 David Katz, Analog Devices http://tech.opensystemsmedia.com/embedded-software/?guid=73f3c9814762fcb152522508e486e506

The days are over when selecting a processor was a relatively simple task, in light of today’s converged processing paradigm. But examining a few key considerations can ease the decision-making process.

Selecting an embedded processor used to be a pretty straightforward task. Of course, this was back in “the old days,” when the focus was on a limited set of functions, user interface and connectivity didn’t matter too much, and power consumption wasn’t such an overarching issue. In today’s realm of converged processing, where a single device can perform control, signal processing, and application-level tasks, there’s a lot more to consider (Figure 1). While there are too many aspects of the processor selection process to detail here, let’s examine some of the more prominent areas that system designers must consider.

Processor performance

System designers reflexively note the processing speed of a device as a major indicator of its performance. This is not a bad start, but it’s an incomplete assessment. It is clearly important to evaluate the number of instructions a processor can perform each second, but also to assess the number of operations accomplished in each core clock cycle and the efficiency of the computation units. And it is no longer uncommon to employ processors with multiple cores as a way of greatly extending the computational capabilities of the device (especially in the case of homogenous cores) or clearly demarcating the control processing from the signal processing activity (often with heterogenous cores).

Hardware acceleration

Of course, it’s not just about the processor core(s). For execution of well-specified functionality, a hardware accelerator is almost always the most power-efficient method to perform the function it was designed to accelerate. One area that can make the difference in using the accelerator is how friendly it is to use in a software algorithm. For full-algorithm-type accelerators, such as an H.264 encoder, there usually is not an issue because it’s substantially self-contained. However, for kernel-type accelerators like an FFT, it can be more challenging to use an accelerator within a larger algorithm. Take a look at how the hardware function performs and how it needs to be configured.

Bandwidth requirements

Bandwidth estimation is a process that’s easy to oversimplify, sometimes with unfortunate results. All individual data flows in the system must be summed (with directionality and time window taken into account) to ensure that the core is capable of completing its data processing within the allotted window, and that the various processor buses are not overloaded, leading to data corruption or system failure. For example, for a video decoder, designers need to first account for reading the data that needs to be decoded. Then, it is necessary to incorporate the many data passes required to create the decoded frame sequence. This may involve multiple buffer transfers between internal and external memories. Finally, designers must account for the streaming of the display buffer to the output device.

After all data flows are considered, the overall system budget needs to be constructed. This budget is influenced by several factors, including DRAM access patterns (and resulting performance degradations), internal bus arbitration, memory latencies, and so on.

Power management

The ability to throttle power consumption to a level commensurate with temporal operating requirements is crucial to preserving battery life, as well as overall energy costs in mains-powered systems. Processors can offer a wide range of options for optimizing an application’s power profile. One such feature is dynamic power management – the ability to adjust core frequency and operating voltage to meet a certain performance level. Another is the availability of multiple power modes that turn off various unneeded resources, including memories and peripherals, during certain time intervals. System wakeup (through general-purpose I/O, a real-time clock, or another stimulus) is an integral part of this power mode control. Yet another degree of flexibility in power management is the presence of multiple voltage domains for core, I/O, and memories, allowing different system components to operate at lower voltages when practical.

Security needs

Over the past several years, processor security has become increasingly important. Whether or not such a scheme is a baseline requirement of a system, it is essential to view the security question from multiple vantage points before deciding on the final direction. Security needs usually take the form of platform protection, IP security, or data security – or some combination of all three.

Platform protection is needed to ensure that only authenticated code is run in the application. In other words, must “rogue code” be actively prevented from running? By “rogue code,” we refer to a program that tries to access protected information on the processor, or “hijack” the processor and gain control of the larger system. Platform protection can be implemented with a variety of techniques, and there are always trade-offs to consider in the selection. As with any trade-off, there is a cost implication as the protection levels increase. Another important consideration is the ease-of-use of the overall security scheme, both in development and in production.

The ability to authenticate code is also critical to securing IP and data. IP security requires a way to either encrypt the code image brought into the processor for execution, or to store this IP internal to the processor through embedded flash or an internal ROM inaccessible through external mechanisms. Some form of data security is required to ensure that data enters and exits the system without being compromised. In some cases, especially in lower-end microcontrollers, security may be handled completely with embedded flash, but on higher-end processors, where the application is loaded in through a boot loader, the scheme may be more complex.

Safety and fault tolerance

There are many applications where safety is clearly a main concern, for example, an automotive driver assistance system or a closed-loop power control system. However, currently designers of other not-so-obvious applications are starting to care more about increasing levels of operational robustness. This is especially true as processors are built in smaller silicon geometries, such as 28 nm or 40 nm, for example, where soft errors in memory can impact operations because of naturally occurring events, including alpha and gamma particles. During the processor selection process, it’s important to examine how a processor handles these types of errors, as well as how it responds to unexpected events in general. What steps can it take when an error occurs? How does it signal to other system components that something has gone wrong?

Debugging capabilities

As applications become more complex, so does the development process. Shortcuts that worked in the past might not work when the number of processor and application subcomponents has grown exponentially. Consider the system-level debug of a large software-based system that uses an operating system or real-time kernel. Do the processor and its tool chain have a way to examine the processor state without impacting the application? Is it possible to profile and trace where the processor has been, or to trap on all events of interest? All these questions, and many more, should be answered before becoming comfortable with the level of debugging available.

System cost

At times, system designers focus on the processor price tag instead of the overall system design cost. It is imperative to take into account not only the device cost itself, but also cost of the supporting circuitry required – level translators, interface chips, glue logic, and so on. Also, package options play a vital role: One processor’s package might allow a four-layer board design, while another’s may necessitate an expensive six- or eight-layer board because of routing challenges. Finally, don’t overlook the value of extra processing headroom that can allow for future expandability without causing an expensive processor change or board spin.

Signal chain

One final note: Processor selection should occur in tandem with a study of a system’s signal chain requirements. Does the processor vendor also sell peripherals that connect to the processor? It is often advantageous to buy multiple system components from the same vendor – for interoperability, customer support, and overall pricing benefits.

Ready to choose a processor?

As mentioned, there are many other facets to consider during the processor selection phase, but the considerations described here should provide a good basis for embarking on this crucial process. Vendors such as Analog Devices offer a wide range of processors and other components that meet the described selection criteria.

David Katz is New Processor Applications Manager at Analog Devices, Inc. Previously, he was a Senior Design Engineer at Motorola, Inc., in cable modem and automation groups.

Rick Gentile is Director of DSP Applications and Systems Engineering at Analog Devices, Inc. Prior to ADI, he held a variety of signal processing and embedded processing engineering positions.

Analog Devices, Inc. www.analog.com/processors

Follow: Twitter Blog Facebook Google+ LinkedIn YouTube

]]> http://tech.opensystemsmedia.com/embedded-software/2013/02/choosing-a-processor-is-a-multifaceted-process/feed/ 0 http://www.embedded-computing.com/articles/id/?5919 http://www.embedded-computing.com/articles/id/?5919#comments Fri, 08 Feb 2013 15:00:00 +0000 Bill Weinberg, Olliance Consulting http://tech.opensystemsmedia.com/embedded-software/?guid=59f75b03640e366534b16655b0fc25ea

With the smorgasbord of Open Source Software (OSS) available for developers to dine from, it’s vital they
“eat right” by choosing the OSS compatible with their existing project and IP needs.

Open Source Software (OSS) offers intelligent systems designers a veritable smorgasbord of tools and technology. Spanning the entire software stack, from boot code and drivers to OSs, executives to middleware, and application components to development tools, OSS provides readily available alternatives to both legacy commercial software and also to in-house code developed from scratch.

But dining at the open source table is not an embedded bean feast – code gathered à la carte might not always integrate easily to make a well-formed “meal.” While literally millions of OSS projects are available on popular forges and hubs, developers must take care to choose the right technology ingredients and tidbits to fit project and intellectual property needs.

The following examines resources and tools for discovering OSS projects and metrics for those projects. It also explores factors to consider when choosing OSS projects and components for embedded designs. And it serves up heuristic methods for choosing the OSS technology most appropriate to real-world embedded development needs.

Discovering embedded open source

Finding open source software is easy. Finding the right piece of OSS can be much harder. Luckily, options for finding and evaluating OSS are plentiful, and come in five categories: search engines, hosting sites, individual project sites, dedicated OSS discovery tools, and embedded platform distributions.

Search engines

Google, Yahoo!, Bing, Baidu, and other general-purpose search engines actually do an okay job at ferreting out OSS projects. A quick search on the string “open source embedded database,” for example, yields a rich mix of references and actual project sites and repositories. But while search engines are an okay starting point, using them can yield scattershot results.

Hosting sites, foundations

Another path is to go right to the source – the forges and hubs that host multiple projects. Until a few years ago, SourceForge would have been a developer’s prime destination, with its collection of 450,000 project repositories. But today, new projects are likely to find homes on GitHub (with 2.4M unique repositories), CodePlex (32,000 projects), Google Code (10,000 projects), Gitorious, and a long tail of other sites.

Yet another type of locale for project hosting is the gamut of open source foundation forges – the Apache Foundation, CodePlex Foundation, the Eclipse Foundation, and others. These sites bring together usually related bodies of code (for example, IDE elements and plug-ins for Eclipse) and can boast several hundred hosted projects.

While repository aggregations and foundation sites are searchable by themselves, each still constitutes a distinct silo; however vast their portfolios may be, they don’t cover the entire universe of open source.

Project sites

Some projects eschew the crowded forges and build their own dedicated Web sites and repositories. These may be projects of broad community interest, of greater maturity, or merely the result of technical vanity. In any case, the main challenge is still finding the project, not in the relatively limited haystack of a forge but in the larger universe of the World Wide Web.

Discovery portals and tools – The Michelin Guide of OSS

Probably the shortest path to finding and also evaluating open source projects lies in portals that help developers discover, track, and compare open source code and the projects behind them. These free portals include Ohloh.net (owned by Olliance Consulting parent company Black Duck), Google Code Search, and others. These services track the full gamut of open source software, and like the projects they monitor, they are themselves open, letting users introduce new project repositories for cataloging and analysis.

OSS management platform tools also exist to help developers discover suitable homemade open source as well as “in the wild.” At companies with established policies for OSS use and deployment, developers can use these tools to peruse directories of vetted/approved open source code documented and/or maintained by their employers. These portfolios can also include code built and managed under the umbrella of “inner-source” and “corporate source” programs.

Embedded platform distributions – Prix fixe meals

If the organization has already committed to a prepackaged embedded platform distribution – a commercial or community-based Linux tool kit, an Android SDK, or equivalent – then engineers already have a library of applications, middleware, and utilities at their fingertips. Embedded distributions typically comprise 250 to 500 packages, with each package containing one or more unique, ready-to-use pieces of project code. Unlike downloading code directly from project sites, embedded distributions and SDKs usually include prebuilt versions of project code, tested and vetted for integration compatibility across packages. In many cases, these versions might not be the latest and greatest, and developers might need to turn to the original project sites to access the more current features and bug fixes. However, switching to newer versions of projects, while attractive, can break compatibility with other code in your stack, and also fall outside Service-Level Agreements (SLAs) from commercial suppliers.

Evaluating options, refining the OSS palate

Finding potentially useful code represents only half the challenge. Developers must also vet discovered code across a variety of parameters to determine if it is technically and legally viable. Factors to consider include code size, language, and quality; community history and dynamics; software licensing; and provenance.

Code size – Legacy embedded designs face severe constraints on code size. While tumbling DRAM and flash memory prices have made parsimonious provisioning a concern of the past, embedded software still benefits from compact code. Memory and storage eaten up by utility and infrastructure code are unavailable for differentiating software and for end-user content.

Because OSS starts with source code, the memory footprint of a given project or software component isn’t always obvious. Moreover, today’s device-based software stacks can contain ingredients cooked up in traditional compiled/assembled languages (C, C++, assembly), byte-code executed Java, and scripted/interpreted languages (PHP, Python, Lua, and so on).

The sites and tools mentioned earlier report both the language of projects and the Lines of Code (LoC) in each. If a project is truly size-sensitive, the best approach is to download and build the source code to determine actual binary size (or just examine the total size of scripted/interpreted code). Figure 1 uses Ohloh reports to compare source code growth in three database projects over time.

Language – Implementation language is as important as functionality and size. If a project is being developed in C, projects in Java or Python probably won’t integrate well into the existing or planned software stack.

Code quality – Code quality can prove rather difficult to gage. OSS discovery portals do report how well commented/documented OSS projects are. Other tools exist to vet the quality of code contained within a project, for example, open source Sonar and the popular Coverity suite.

Community dynamics – Important metrics of the health and quality of open source projects lie in the size and activity of the community behind it. Some hosting sites offer historical participation metrics, and some sites include contributor data and activity over the lifetime of a project. Figure 2 uses Ohloh reports to compare the waxing and waning of the developer community over time for three database projects.

Commit history – Tied to community dynamics is the commit history for a project – how often are changes committed to project repositories, over the project lifetime and for recent timeframes? In an immature project, change can appear to be fast and furious; for moribund projects, commits drop away to zero. Viable, stable, mature projects lie somewhere in between.

Licensing – Dealing with the diversity of open source license types and requirements is beyond the scope of this article. Of the 2,200+ recognized licenses, developers are most likely to encounter perhaps a dozen. (See a list of the top 20 open source licenses at http://osrc.blackducksoftware.com/data/licenses/; these account for 90 percent of all projects). The most important open source licenses are the GNU General Public Licenses (GPL, LGPL, AGLP), the Apache License (APL), the BSD license, the Mozilla Public License (MPL), the Eclipse Public License (EPL), and a handful of others. Learn more about these and others at the Open Source Initiative, OpenSource.org.

A larger challenge lies in reconciling project licensing with a company’s Intellectual Property Rights (IPR) governance and compliance programs. A related challenge is reconciling the requirements of different licenses for diverse code integrated into a single software stack.

Provenance – Knowing the actual origins of code can also help in finding support for code, as well as protecting the company from potential legal challenges. Many useful and important projects are associated with commercial organizations that help maintain the project and provide support for it. Most projects have a unified copyright (note: the Linux kernel does not), and many have established processes for determining provenance (for example, certificates of origin for code submission).

The choosy OSS diner

The goal here has been to serve code-hungry developers useful pointers for discovering, vetting, and ingesting open source software. The diversity of options and the surfeit of licenses need not require a particularly adventuresome technology palate – OSS is today truly mainstream and it is a rare embedded project that does not use and/or deploy open source software tools and components.

Matching the right OSS technology to your project is less like rocket science and more like pairing wines and food. More time “tasting” OSS will teach you where to look for compatible coding languages.

Bill Weinberg is Senior Director of Olliance Consulting, a division of Black Duck Software.

Olliance Consulting, a division of Black Duck Software info@blackducksoftware.com www.ohloh.net

Follow: Twitter Blog Facebook Google+ LinkedIn YouTube

]]> http://tech.opensystemsmedia.com/embedded-software/2013/02/eating-right-at-the-open-source-buffet/feed/ 0 http://www.embedded-computing.com/articles/id/?5921 http://www.embedded-computing.com/articles/id/?5921#comments Fri, 08 Feb 2013 15:00:00 +0000 David Kleidermacher, Green Hills Software http://tech.opensystemsmedia.com/embedded-software/?guid=cec2d43c5bbe7b3490ff4ff1944f24e6

Android has its share of benefits and challenges when it comes to automotive infotainment systems. One such challenge is that of the emergence of mixed-criticality systems comprising both infotainment and safety-/security-critical systems, enabled by high-performance multicore processors. To face this challenge: Try virtualization.

Android represents a compelling choice for automotive infotainment systems. As the most popular and fastest-growing mobile Operating System (OS) – comprising two-thirds of worldwide smartphone shipments1 – automotive OEMs see Android as the means to provide the best possible multimedia experiences. Android provides standardized interfaces for accelerated graphics, audio, wireless networking, Bluetooth technology, USB, and more, enabling applications to easily harness the power of these hardware facilities. OEMs see Android as a means of leveraging consumers’ familiarity with mobile devices to improve the automotive experience.

The availability of the Android open-source infotainment platform comes at a time when OEMs are taking more control over the digital infrastructure in cars. The traditional model of outsourcing the entire infotainment system to Tier 1 component suppliers is being replaced (at least at some OEMs, to varying extents) with an approach in which the OEM chooses the operating system, development environment, and microprocessor platform and even performs a significant amount of software development. Tier 1s are asked to build hardware and provide application and driver work, but the OEM owns the architecture. Android provides the control that OEMs require in this new world. But while these advantages are attractive to OEMs, Android also poses some challenges when it comes to multiprocessor-enabled, consolidated in-vehicle systems that tuck safety- and security-critical applications and infotainment applications all into a single system; however, virtualization is effectively conquering these challenges.

Challenges with Android in the car

In 2012, for the first time in its 26-year history, the J.D. Power Auto Quality Study found that the infotainment system is now the biggest source of problems in new cars. Therefore, OEMs are justifiably concerned with the reliability, stability, and security of Android.

Android’s extremely large source code base coupled with its open source development model results in extreme churn – literally thousands of edits per day across Android and its underlying Linux kernel. This guarantees a steady flow of vulnerabilities. A quick search of the U.S. CERT National Vulnerability Database turns up numerous vulnerabilities of varying severity for in-vehicle infotainment systems. Here is a sampling of the worst offenders:

• CVE-2012-4190: allows remote attackers to cause a denial of service or execute arbitrary code
• CVE-2011-0680: allows remote attackers to read SMS messages intended for other recipients
• CVE-2010-1807: allows remote attackers to execute arbitrary code
• CVE-2009-2999, -2656: allows remote attackers to cause a denial of service (application restart and network disconnection)
• CVE-2009-1754: allows remote attackers to access application data
• CVE-2009-0985, -0986: buffer overflows allow remote attackers to execute arbitrary code

We point these particular vulnerabilities out because they fall into the highest severity category of remote exploitability. They are used by hackers to root Android phones and tablets, and automotive manufacturers want to ensure that the same vulnerabilities do not threaten Android- or Linux-based infotainment systems.

Another concern with Android is driver/passenger safety. Automotive electronics architecture is in the midst of a major trend reversal: Instead of adding more and more processors for new functions, disparate functions are being consolidated into a smaller number of high-performance multicore processors in order to reduce size, weight, power, and component/wiring cost. Processor consolidation is leading safety-critical systems to be integrated with infotainment. The consolidation trend is aided by next-generation, performance-efficient multicore processor platforms, such as the “Jacinto” and OMAP processor families including TI’s OMAP 5 platform, which offers a dual-core, power-efficient ARM Cortex-A15 processing architecture.

Additionally, such mixed-criticality system consolidation, for example, includes OEMs looking to host real-time clusters, rear-view cameras, and Advanced Driver Assistance Systems (ADAS) within the center stack computer. Next-generation Android infotainment systems must ensure that applications and multimedia seamlessly interact with safety functions, and pose no risks to passengers.

Meeting safety- and security-critical challenges

OEMs cannot depend on Android to control all aspects of next-generation infotainment systems. Android cannot boot fast enough, cannot guarantee real-time response for protocols such as CAN, and is not reliable enough for safety-critical functions such as ADAS and integrated clusters. OEMs need a system architecture in which Android and its applications can peacefully coexist with real-time, critical applications.

A number of OEMs are looking to virtualization as the solution to next-generation infotainment system architecture. With a specialized form of real-time hypervisor, the platform can host Android within a virtual machine alongside, but safely isolated from, lightweight applications that use open standard APIs to perform real-time, safety- and security-critical functions, such as automatically applying the brakes when a child is detected by the car’s back-up camera.

One example of such a hypervisor is Green Hills Software’s INTEGRITY Multivisor, built upon the INTEGRITY separation kernel, used extensively in automotive infotainment and other mission-critical applications. With this kind of virtualization solution, the infotainment computer can achieve astounding boot times measured in milliseconds, to handle instant-on tasks such as responding to CAN messages – including adjusting seat controls or reporting a transmission error – and bringing up the rear-view camera. With a platform that enables this mixed-criticality architecture, OEMs can reduce size, weight, power, and cost in the electronic infrastructure while taking advantage of the latest Android bells and whistles.

Applying this hypervisor architecture to the aforementioned system – consisting of the main infotainment OS and safety-critical applications for rear-view camera and driver information cluster – results in the architecture shown in Figure 1.

In addition to previously mentioned safety applications, security-critical functions can be partitioned from Android, enabling a form of security retrofit to an otherwise vulnerable environment. The transmission of sensitive information – such as a personal contact book or garage door code – over vehicular networks and the storage of private consumer or OEM data within Android’s storage system can be hardened using the hypervisor as shown in Figure 2.

Android has a powerful standardized sensor capability, with support for acceleration, magnetometer, temperature, gravity, gyroscope, touch proximity, and light detection. These features are incredibly important in both safety and infotainment systems. Automotive app developers can use these standard APIs to detect conditions in which certain applications or services should be inhibited. Android’s standard vibration and sound APIs, for example, can be used to provide the driver with haptic and audio feedback when visualization is discouraged. In a virtualized environment, the hypervisor must be capable of safely multiplexing peripherals that are needed by the Android environment and critical applications.

The promising road ahead

Android represents a tremendous opportunity for automotive OEMs to leverage the latest and greatest consumer electronics technology for an enhanced driver and passenger experience while providing a maximum level of control and customization. OEMs must be prepared to develop in-house Android expertise to bridge the gap between what the open source Android ecosystem provides and what is practically needed to develop a comprehensive infotainment system and cloud-based app store and services environment.

Automotive electronics require a systems software architecture that enables an Android infotainment stack to be delivered with the reliability, safety, and real-time performance that OEMs and consumers demand, particularly in light of the consolidation trend. The combination of virtualization and powerful multicore processors can help realize this vision.

David Kleidermacher, Chief Technology Officer, joined Green Hills Software in 1991 and is responsible for technology strategy, platform planning, and solutions design. He is a leading authority in systems software and security, including secure operating systems, virtualization technology, and the application of high-robustness security engineering principles to solve computing infrastructure problems. David earned his Bachelor of Science in Computer Science from Cornell University.

Green Hills Software www.ghs.com/products/rtos/integrity_virtualization.html

Follow: Twitter LinkedIn YouTube

Texas Instruments Incorporated (TI) www.ti.com

Follow: Twitter Blog Facebook Google+ LinkedIn YouTube

]]> http://tech.opensystemsmedia.com/embedded-software/2013/02/the-future-of-android-in-vehicles/feed/ 0 http://www.embedded-computing.com/articles/id/?5884 http://www.embedded-computing.com/articles/id/?5884#comments Tue, 11 Dec 2012 15:00:00 +0000 Jennifer Hesse, Editor, OpenSystems Media http://tech.opensystemsmedia.com/embedded-software/?guid=c910342ca481fb1e4c160cc9e86217c2

Created from the ground up to address multicore and parallel computing, the Scala programming language smoothly integrates features of object-oriented and functional languages, enabling developers to be more productive while retaining full interoperability with Java. Mark explains how Scala-based middleware technology can maximize modern multicore hardware and cloud computing software by raising the abstraction level for building multithreaded applications.

ECD: What are the advantages of using general-purpose programming languages like Java and Scala for embedded development?

BREWER: Scala is a general-purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. Scala smoothly integrates features of object-oriented and functional languages, enabling developers to be more productive while retaining full interoperability with Java and taking advantage of modern multicore hardware.

Scala is also a functional language. Inspired by the long tradition of functional programming, Scala makes it easy to avoid shared state so that computation can be readily distributed across cores on a multicore server and across servers in a data center. This makes Scala an especially good match for modern multicore CPUs and distributed cloud computing workloads that require concurrency and parallelism.

Scala is equipped with an expressive type system that detects and avoids many kinds of application errors at compile time. At the same time, a sophisticated type inference capability frees developers from the redundant type information “boilerplate code” that is typical of Java.

Because the code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application, Scala is well suited for an embedded environment due to its lightweight and concise nature, as demonstrated in the following code samples:

Java class definition

public class Person {

public final String name;

public final int age;

Person(String name, int age) {

this.name = name;

this.age = age;

}

}

Equivalent Scala class definition

class Person(val name: String, val age: Int) {}

Java code

import java.util.ArrayList;

…

Person[] people;

Person[] minors;

Person[] adults;

{ ArrayList<Person> minorsList = new ArrayList<Person>();

ArrayList<Person> adultsList = new ArrayList<Person>();

for (int i = 0; i < people.length; i++)

(people[i].age < 18 ? minorsList : adultsList)

.add(people[i]);

minors = minorsList.toArray(people);

adults = adultsList.toArray(people);

}

Equivalent Scala code

val people: Array[Person]

val (minors, adults) = people partition (_.age < 18)

Scala protects investments in existing Java libraries, tools, and developer programming skills. Scala programs are compiled directly to Java bytecode that runs on the mature Java Virtual Machine (JVM), leveraging its robust just-in-time compilation, garbage collection, and well-understood deployment techniques. The operations team doesn’t see a difference. Developers keep working with their familiar tools, but they’re writing code that’s shorter, faster, more scalable, more correct, and maybe even more fun.

ECD: How does the latest wave of multicore processors affect software development with object-oriented programs?

BREWER: The Java programming language was created in 1995, so it was suited to handle the first generation of Internet applications, with object-oriented programming models, multiplatform runtime, and network orientation. However, with the advent of cloud computing and interactive applications that demand near real-time capabilities, the Java language and traditional Java middleware have begun to show their age when faced with the equally significant hurdles of large-scale distributed applications and multicore platforms.

In most languages, the key to utilizing the full power of multicore CPUs is by writing concurrent multithreaded applications. Considering the shared state, state visibility, threads, locks, concurrent collections, and thread notifications involved, writing this type of application is difficult, even for experienced developers. These concepts are by nature error-prone and often result in deadlocks or application crashes.

In an attempt to keep up with the times, Java has evolved, but has become bulky and cumbersome in the process. Java and Java Enterprise Edition (JEE) application servers are inherently difficult to scale predictably; scaling up is extremely hard to accomplish, and the commercial licensing terms offered by most vendors prohibit the economical scale-out that customers so desperately need as an alternative to this model.

Another essential component of building scalable applications for embedded devices is middleware. Akka, built upon the scale afforded by the Scala programming language, is a message-oriented programming model for building multi-threaded applications. Akka raises the level of abstraction so that developers only need to worry about messages and business logic, instead of dealing with the low-level plumbing required in Java.

Play! builds upon Akka to deliver a Model-View-Controller (MVC)-style Web framework with a development experience much like that enjoyed by Rails developers. Play-mini is a subset of the Play! framework that consists of a REST layer on top of the Netty non-blocking I/O socket server. It offers the ability to deploy Akka applications for service-layer jobs that don’t need the rest of the Play tools (for example, the MVC/interface layer).

ECD: How does advanced middleware technology enable developers to build better software for the cloud?

BREWER: Akka is an event-driven middleware framework implemented in Scala for building reliable, high-performance distributed applications. It raises the abstraction level for the developer, removing the need to worry about the low-level plumbing required to create highly concurrent applications in languages such as Java.

Raising the abstraction level is key for building better software in the cloud. Developers can focus on implementing business logic and adding value, not spending time worrying about implementing low-level features such as high-availability services and state/memory management. With Akka, the developer gets an ideal fabric for the cloud that is:

• Elastic and dynamic, with the ability to expand and contract based on the actual load the system is experiencing
• Fault-tolerant and self-healing, where the system detects failures automatically and can restart individual components or entire servers based on the business requirements
• Customizable and adaptive load-balancing, where software components can route messages based on system load or any other user-definable criteria
• Configured so that clusters can rebalance the load in failover situations via actor migration, where actors are moved between systems dynamically

The bottom line is that it’s very easy to build loosely coupled and dynamic systems that can almost organically change and adapt at runtime.

ECD: Briefly explain Typesafe’s technology and the current applications for it in an embedded computing environment.

BREWER: Typesafe’s vision is to enable development of concurrent, fault-tolerant applications with a single unified programming model, managed runtime, and binary compatible distribution.

Typesafe was founded in 2011 by the creators of the Scala programming language and Akka middleware, who joined forces to create a modern software platform for the era of multicore hardware and cloud computing workloads. The company provides an easy-to-use packaging of Scala, Akka, Play!, and developer tools through both an open-source stack and a commercial stack that provides commercial support, maintenance, and operations tools via the Typesafe Subscription. In conjunction with its partners, Typesafe also provides training and consulting services to accelerate the commercial adoption of Scala, Akka, and Play!

Companies that use the Typesafe Stack in an embedded way typically rely on its low latency, high throughput, and resiliency design points. It is used as for handling millions of messages per second across networks and network devices.

ECD: What challenges are your customers dealing with right now?

BREWER: Performance at scale is a main driver for customers to consider the Typesafe Stack. We’ve found that customers who have tried the traditional development paradigms using JEE application servers, PHP, and Ruby hit a performance or efficiency wall. In addition to being highly efficient, the components of the Typesafe Stack are compact from both a disk and memory standpoint, especially when compared to the traditional JEE application server, and lend themselves well to the embedded space.

Mark Brewer is president and CEO of Typesafe.

Typesafe mark.brewer@typesafe.com typesafe.com

Follow: @typesafe Facebook Linkedin

]]> http://tech.opensystemsmedia.com/embedded-software/2012/12/a-modern-software-platform-for-the-era-of-multicore-and-cloud-computing-qa-with-mark-brewer-president-and-ceo-typesafe/feed/ 0