• No results found

Wind River Lab Diagnostics 2.2

N/A
N/A
Protected

Academic year: 2021

Share "Wind River Lab Diagnostics 2.2"

Copied!
10
0
0

Loading.... (view fulltext now)

Full text

(1)

Wind River Lab Diagnostics links development and test teams in an intelligent, collaborative workflow. A scalable, distributed software diagnostics system, it enables development and test engineers to use Sensorpoints to dynamically test, characterize running applications, perform fact-based analysis, and rapidly resolve issues encountered throughout the QA phase. Lab Diagnostics enables development teams to design testability into devices by embedding a minimally intrusive agent—providing insight into running applications through Sensorpoints, core files, and exception logs. Lab Diagnostics’ enterprise-wide infrastruc-ture allows distributed development and test teams to collect, aggregate, exchange, and analyze data from multiple devices under test at multiple locations—streamlining the QA phase. In general, Lab Diagnostics enables teams to do the following:

Test:

• Use Sensorpoint technology to efficiently develop tests for functionality, performance, and coverage

Automate:

• Create scripts to simultaneously and efficiently run multiple tests across multiple devices

Wind River Lab Diagnostics 2.2

As the amount of code embedded in devices and systems continues to increase, the challenge of integrating, verifying, and validating it also expands. Engineering teams are routinely required to implement and test an ever-increasing number of features with set deployment dates, shrinking the time available for development and quality assurance (QA) testing. Developing run-time software and tools to comprehensively test embedded software is time-consuming and distracts the development team from implementing new features. Once a defect is discovered in the lab, development engineers must try to reproduce and repair it, then resubmit the product to the test teams in a cycle that consumes essential resources. Current methods of testing, while beneficial, traditionally require lengthy debug, code, build, reload, and test cycles. If the development team is distributed over a broad geographical area, different time zones impact communication and further extend the QA phase.

Development engineers are charged with writing, integrating, and verifying “perfect” applications, while test teams are charged with validation of product design. Both must also root out software faults that would be difficult and costly to repair after the device is deployed.

Table of Contents

New in This Release... 2

Apply Fixes Without Rebuilding via Patchpoints ... 2

Sensorpoint Log Improvements ... 2

Sensorpoint and Patchpoint Validation with Metadata ... 2

Database and J2EE Application Server ...2

Key Benefits ... 2

Faster Testing, Risk Mitigation ... 2

Faster Time-to-Resolution ... 2

Test More Software, Detect More Defects ...3

Components and Features ...3

Wind River Workbench Diagnostics ...3

Device Management Server ...3

Site Manager (Optional) ...3

How to Apply the Software ...4

Cross-Development Workflow ...4

Laboratory Environment Workflows ...7

Sensorpoint Technology ...8

Specific Applications of Sensorpoints for Development and Test ...8

Technical Specifications ...9

Workbench Host OS Support ...9

Server Host OS Support ...9

Target OS Support ...9

Target Architecture Support...9

Wind River Software Requirements ...9

Third-Party Software Requirements ...9

Wind River Device Management ...9

Wind River Field Diagnostics ...9

Partner Ecosystem ...10

Professional Services ...10

Education Services ...10

(2)

Diagnose:

• Analyze diagnostic data to isolate the root cause of intermittent bugs, lockups, and crashes

Resolve:

• Use Patchpoints to apply patches to devices without rebuilding, saving valuable time for the QA team

New in This Release

Apply Fixes Without Rebuilding via Patchpoints

Patchpoints have been introduced as a method to dynamically repair applica-tions that are embedded in devices or systems without rebuilding. Wind River’s proven Sensorpoint technology is used to implement Patchpoints. In addition, Patchpoints have been optimized specifically for patching code. The workflow for creating, managing, and deploying Patchpoints is similar to that of Sensorpoints. They can be created using Wind River Workbench Diagnostics or using a standard editor. However, Patchpoints can be written in standard C and C++ code instead of using Sensorpoint commands. This allows their code to be consistent with existing project code and saves users from learning the Sensorpoint commands. Patchpoints are supported on VxWorks targets in this release only.

Sensorpoint Log Improvements Log files can now be analyzed directly from the Device Management Server or Site Manager. The interface has also been improved so that it is easy to correlate each log file to its respective Sensorpoint binary module.

Sensorpoint and Patchpoint Validation with Metadata

Users can now tag Sensorpoints with metadata to denote the microprocessors and operating systems that will support the Sensorpoint code. Lab Diagnostics then uses this information to enable the Sensorpoint only on devices that share the same metadata.

Database and J2EE Application Server The JBoss J2EE application server and Hypersonic SQL database are now distributed with the product in compli-ance with their open source licenses. These are intended for trial and small project use, whereas commercial databases and application servers are also supported for higher volume production use.

Key Benefits

Faster Testing, Risk Mitigation

Lab Diagnostics enables teams to adopt a repeatable process for rigorously testing running software, detecting software bugs, and correcting faulty software. It does this by breaking down the wall between developers and QA staff by providing a single enterprise software solution that can be used by both teams. This fosters strong collabo-ration and knowledge share between the two teams. For instance, when the QA team detects a defect, developers can access detailed logs and fault data in order to quickly reproduce the defect in their own environments. Also, with Sensorpoint technology, the QA team can easily access a code instrumentation library created by the developers and leverage it to create their own system tests. The library can then be reused and evolved further in future projects.

Faster Time-to-Resolution

Nowadays device software takes several hours to build. When the build is broken or has defects that prevent thorough testing, the entire testing effort can be blocked while testers await the fix in the next build. These delays can add up and increase a product’s time-to-market. Lab Diagnostics prevents these delays and streamlines the fault isolation and problem resolution process. Enabling fact-based analysis of software defects, it eliminates much of the time developers traditionally spend trying to reproduce intermittent problems encountered during test. Sensorpoints enable development and test engineers to obtain more information by dynamically placing instrumentation code in prob-lematic applications. Both the developer and tester have analysis tools to isolate the root cause. With the problem isolated, developers can easily create and publish a Patchpoint when creating a fix, which the QA team then applies to the build to realize the fix immediately. If rebooting the device requires a lot of time or effort, the Patchpoints can even be applied “hitlessly” to running devices.

Figure 1: Wind River Lab Diagnostics

Wind River

Workbench Diagnostics

Management Server

Device

Development

System Under Test

Network

(3)

Test More Software, Detect More Defects

Lab Diagnostics enables teams to transition from a common test method with in-application test hooks to a more efficient real-time dynamic testing. This means that white-box testing of embed-ded software is performed on a live running system, without need to rebuild the application or restart the device. This more closely approximates how a device will run once deployed in the real world, so test engineers can comprehensively test the embedded application.

Sensorpoint technology allows testers to increase code coverage, tune the performance of software, and inject faults into running applications. With scripting support, regression tests and long-run tests can be automated to increase the number of test cycles per project. This allows developers and QA staff to increase software quality.

Components and Features

Wind River Workbench Diagnostics Wind River Workbench Diagnostics is the developer-centric portion of Lab

Diagnostics. It plugs into Wind River Workbench, an Eclipse-based develop-ment suite, and integrates with its powerful development tools. Workbench Diagnostics enables developers to design run-time software into the operating system—enabling a testable platform. It facilitates Sensorpoint and Patchpoint development, deployment, management, log collection, and log analysis. Workbench Diagnostics enables developers to extract core files gener-ated by VxWorks 6 and to perform core file analysis with the Workbench Debugger. When fault data from devices under test reaches the development team, Workbench’s analytic and visualiza-tion tools expedite understanding and resolution of software defects.

Sensorpoint/Patchpoint Development Development engineers can write Sensorpoints or Patchpoints and then insert them into designated places in the application code, using the Eclipse-based editor in Workbench.

Sensorpoint/Patchpoint Compiler A compiler generates Sensorpoint and Patchpoint binaries from raw code.

Sensorpoint Autogeneration

Multiple Sensorpoints can be generated simultaneously within selected functions without manually writing Sensorpoint source code.

Core File Analysis

Core file analysis allows Workbench Debugger to recreate the system state at the time of failure, in order to perform root cause analysis of device crashes or reboots.

Sensorpoint Log Analysis

The Sensorpoint Log Viewer allows users to inspect and analyze data logs from devices. The Wind River System Viewer tool can also be utilized to visualize log data in relation to other system events.

Device Connect Plug-in

A plug-in allows users to deploy, enable, disable, and remove Sensorpoints and Patchpoints from a device directly connected to Workbench Diagnostics.

Server Connect Plug-in

A plug-in allows remote access to the server from Workbench Diagnostics in order to upload Sensorpoints/ Patchpoints and download logs.

Device Management Server Device Management Server is an enterprise-class server application that resides in the original equipment manufacturer’s (OEM) virtual lab facility for use by the QA team. It connects via virtual private network (VPN) to distrib-uted development centers. Device Management Server is the hub of Lab Diagnostics, where data is archived, aggregated, and shared by development and test engineers. With the Device Management Server, development teams can streamline collaboration and improve information sharing during development.

Sensorpoint/Patchpoint Management and Control

Store and maintain test-specific Sensorpoints/Patchpoints provided by development engineering. Groups can be created for efficient organization. Selected Sensorpoints or Patchpoints can easily be deployed to devices.

Device Management

Users can organize an array of devices by labeling each with metadata including device model, model categories, proces-sor types, and operating systems. This enables verification against Sensorpoints that only support specific hardware and operating systems.

Device Log Aggregation and Management

Store and categorize device logs received from devices and/or site managers.

Data Exchange with Workbench Diagnostics

Exchange core files and log data between Workbench Diagnostics and the server application.

User Account Administration

Add/remove users, assign roles, edit user information, and reset passwords.

Authentication and Authorization Authenticate users and enforce access control to server services.

Database Support

Relational Database Management System (RDBMS) is supported to enable commercial databases.

Site Manager (Optional)

Enterprises with more than one develop-ment site can set up a separate server application called Site Manager for each lab. Each Site Manager contains the same full functionality of the Device Management Server. The Device Management Server is then used to access the superset of all sites at once.

(4)

How to Apply the Software

Lab Diagnostics’ productivity workflow shortens engineering cycles from implementation through QA testing. It offers tools and workflows to facilitate designing for testability and the collec-tion, sharing, and analysis of device data from running applications among development and test teams. Lab Diagnostics can be used to test and diagnose running software in two settings: cross-development and laboratory environments.

Cross-Development Workflow Individual developers use Workbench Diagnostics and a development target to test application performance, test execution paths, and isolate run-time problems. Workbench Diagnostics provides developers with Sensorpoint and core file workflows to collect device data, analyze data, and resolve problems in software modules they own.

The Sensorpoint workflow consists of the following:

Sensorpoint development to instrument •

running modules Sensorpoint log analysis •

Issue resolution with Patchpoints •

The Sensorpoint workflow is useful during performance testing, execution path testing, and run-time diagnostics of intermittent issues.

The core file workflow consists of the following:

Core image extraction •

Core file analysis •

Problem resolution with Patchpoints •

The core file workflow is useful during postmortem analysis after the target crashes and reboots. In a cross-

development environment, development engineers can completely observe the behavior of their running binary modules.

Sensorpoint Analysis Workflow During application development, engineers can use Workbench Diagnostics to write, distribute, and deploy Sensorpoints and to collect and analyze Sensorpoint logs. Development engineers can easily write Sensorpoint source code and build Sensorpoint binary modules. By referencing the application source code in Workbench Diagnostics, software developers can create on_entry, on_line, on_offset, and

on_exit Sensorpoints to instrument entry points, lines within the body, offsets from the entry point, and exit points of functions (see Figure 2). In the data analysis stage of the development test, development engineers can collect and analyze Sensorpoint logs generated while testing their software.

Workbench Diagnostics builds on the capabilities of the Eclipse CDT editor within Workbench to facilitate

Sensorpoint development. Workbench Diagnostics allows developers to review the application source code, determine the instrumentation point(s), and generate Sensorpoint source code quickly. The editor has both an applica-tion and a Sensorpoint source code view for easy development of Sensorpoints. Within the context of Application view, the editor provides a pull-down menu to facilitate autogeneration of Sensorpoint source code templates. Within the context of the Senorpoint view, the editor provides highlighting of Sensorpoint syntax.

Once Sensorpoints have been created, the Workbench project system and build system can be used to organize, manage, and build Sensorpoint binary modules (see Figure 3).

Figure 2: A Simple Example of Sensorpoint Code and Instrumentation

(5)

In a cross-development environment, developers can use the Diagnostics Device Connect plug-in to access a device that contains the Device Management Agent. With this setup, developers can directly manage and control Sensorpoint binaries on a specific target (see Figures 4–5).

With Sensorpoint binaries, developers can instrument functions methodically in the application, operating system, device drivers, interrupt-service routines, and so on. The Diagnostics Device Connect plug-in has one-click actions that enable, disable, uninstall, remove, and reset Sensorpoint binaries. This GUI facilitates a methodical approach to determining the root cause of a fault. For each step in the sequence, developers can focus on an area of concern by temporarily placing a Sensorpoint to collect data that will point to other areas of concern. With this tight cycle of instrument-collect-remove, developers can investigate the entire application, ultimately isolating the fault to a line of code. Workbench Diagnostics allows fact-based analysis of system faults, avoiding the misdirection typical of symptom-based analysis.

The Device Connect Command Line complements the GUI-based interface for engineers who prefer a command-line interface (see Figure 6). In addition, developers can automate workflows at their desks by developing scripts that access the command-line interface. Sensorpoints can be written to output data logs for automatic data transfer to the host file system, or they can be written to output data directly to a console. Developers can use either method, depending on need: deep analysis or quick check.

If Sensorpoints are written for unat-tended log collection, the Device Management Agent automatically offloads logs to the appropriate location on the host file system. If needed, developers can poll the target from the Device Connect plug-in to transfer data immediately from the target (see Figure 7). If Sensorpoints are written for immediate data output, Sensorpoint logs can be displayed to a console, such as the kernel shell.

Workbench Diagnostics also facilitates analysis of log data. Developers can easily select data sets from the host file system and review the content using Sensorpoint Log Viewer or Wind River System Viewer. With Workbench Diagnostics, developers can efficiently analyze a large amount of data, quickly focus on suspicious data points, and readily associate them with the applica-tion source code.

Sensorpoint Log Viewer is a data visualization tool provided exclusively in Workbench Diagnostics. The Log Viewer has multiple views that include tabular representation of the log data,

$ downloadSP device1 control_c.usm $ enableSP device1 control_c.usm $ disableSP device1 control_c.usm $ logUpload device1 /log

$ deleteSP device1 control_c.usm Figure 6: Device Connect Command Line Complements Device Connect Plug-in

Figure 7: Uploading a Log from a Device Using Device Connect View Figure 4: Device Connect View with Add Sensorpoint Module Pull-Down

(6)

Application Source Code view, and Sensorpoint Source Code view to help developers easily analyze Sensorpoint data (see Figure 8).

The Workbench System Viewer tool can graphically display Sensorpoint logs (see Figure 9). Workbench Diagnostics provides a conversion tool that imports Sensorpoint logs in XML format and generates data files in System Viewer format.

Core File Analysis Workflow Workbench Diagnostics provides a process and the corresponding tools to generate core images, extract core images from a target, archive core files, and analyze core files. Core images record the state of the running applica-tion at the point of excepapplica-tion. Core files give developers the entire system image for postmortem analysis.

Workbench Diagnostics includes VxWorks 6 kernel components that enable core image generation. Once configured, VxWorks 6 generates core images when a fatal system exception, kernel panic, or kernel task-level exception occurs.

Developers can then configure VxWorks 6 for onboard core file storage or network offload. In the first method, core images are stored in persistent memory on the target and are transferred to the host during target reboot. The second method eliminates local storage by streaming the core image to the host machine or server application as the target shuts down.

With Workbench Diagnostics, developers can attach to and analyze core files in read-only mode at various levels:

assembly or C/C++, memory content, variable/value pairs, and so on (see Figure 10). The remote Systems view, Debug view, Variable view, Kernel Objects view, Stack Trace view, Memory view, Register view, and Symbol Browser fully support VxWorks 6 core file analysis.

Post and Publish Sensorpoints Development engineers can post Sensorpoints (source code and binary modules) with Workbench Diagnostics. The Server Connect view provides a GUI-based interface to connect to the Device Management Server in the engineering lab (see Figure 11). Development engineers can embody their expertise into module-specific Sensorpoints to be used by team members at every phase of the device life cycle.

Figure 11: Upload of Sensorpoints with Server Connect View

Figure 10: Workbench Remote Systems View Attached to a Core File

Figure 9: Sensorpoint Data Displayed with the System Viewer Figure 8: Sensorpoint Log Viewer

(7)

With the Server Connect IDE plug-in and Workbench, development engineers can also download device data collected by others in the lab and made available via the Device Management Server.

Resolve Issues with Patchpoints With Workbench Diagnostics, software developers can incorporate corrective code in the form of Patchpoints to permanently resolve software issues. Using the same workflow as with Sensorpoints, developers can develop, manage, and seamlessly deploy Patchpoints within devices without rebuilding or even restarting the device.

Laboratory Environment Workflows The QA team interfaces with the browser-based Device Management Server software to leverage Sensorpoints and Patchpoints to increase efficiency in testing. If multiple labs are working together in an enterprise environment, the Site Manager may also be used.

Manage Devices and Sensorpoint Modules

The Device Management Server, a J2EE enterprise-class application, enables development and test teams to manage devices under test, Sensorpoint source code files, Sensorpoint binary modules, core files, exception logs, and

Sensorpoint logs. It provides a browser-based console and scripting facility for a manual or automated workflow. The Device Management Server is the Sensorpoint repository for the develop-ment team.

The Sensorpoint view permits engineers to manage Sensorpoint modules. Engineers can group Sensorpoints into device-, application-, test-, and problem-specific groupings (see Figure 12). This allows development engineers to easily share their expertise with the QA team.

Fault Inject, Control Execution Path, and Collect Data

Engineers can download test-specific Sensorpoints that have been published on the Device Management Server to run tests on devices in the lab. With the GUI

interface or scripting framework, engineers can inject faults, force execution paths, and collect data from multiple devices under test. If there are multiple development sites, multiple Site Managers can be installed at every development site.

With the Device view, engineers can download to and enable Sensorpoint modules on devices. Sensorpoints give development teams the ability to access and control running applications by changing the argument and return values of functions (see Figure 13). By dynami-cally manipulating values, engineers can test any running function, and with dynamic instrumentation, engineers can collect device data from running on devices. Test teams can advance software testing by deploying and removing a sequence of Sensorpoints until test coverage of device applications is satisfactory.

Support for scripting enables engineers to manage multiple Sensorpoints in automated, complex, long-run sequences that do not require constant human supervision, meaning that more code can be tested for longer periods, with no risk of data loss if errors occur (see Figure 14). With Lab Diagnostics, engineering teams have complete access to running applications with a minimally intrusive method. Again, there is no need to modify the application source code, rebuild the application image, reload firmware, or reboot the device.

Figure 14: Automation Through a PERL Script Figure 13: Device View on Device Management Server

(8)

Post and Publish Data

The Device Management Server and Site Manager applications are designed to aggregate and transfer device data collected from devices under test. Fault data captured during the QA process is automatically collected onto the server. With the Log view, engineers can manage core files, exception logs, and Sensorpoints logs (see Figure 15). With the Device view, engineers inspect the listing of device-specific data. If a cross-functional team needs to analyze a data set, users can upload data sets to the Device Management Server.

When testing in multiple labs, the Device Management Server becomes the central repository of device data collected in all of the labs. Users can easily manage many logs from multiple devices through the Log view. Once users post data, multiple developers can download logs onto the host computers for analysis.

Deploy Fixes with Patchpoints Lab Diagnostics is an enterprise-wide system to distribute corrective code embodied in Patchpoints. Engineers can develop, distribute, and enable

Patchpoints that contain fixes to known problems. The development team can streamline the resolution process by eliminating time-consuming application

builds, reloading application binaries, and rebooting the system. Once the ideal fix is found, developers can easily move corrective code contained within the Patchpoint source code into the applica-tion source code.

Sensorpoint Technology

Essential to Workbench Diagnostics is the ability to create Sensorpoints to gain visibility into running embedded applications. A Sensorpoint is software used to instrument “live” applications dynamically without modifying the application source code, rebuilding the application, reflashing boards, or rebooting the device. Sensorpoints enable engineers to dynamically patch functions on running devices; access local and global variables within the scope of a function; and remotely monitor, configure, and control the execution of an application. Sensorpoints are minimally intrusive on device

performance. They can be disabled and enabled remotely. Sensorpoints can be created by development engineers, leveraged by test teams, and used by support engineers.

Specific Applications of Sensorpoints for Development and Test

Intelligently Exercise Subsystems and Functions

Inject specific values in variables •

Force conditional expressions to execute •

code paths

Inject faults for routines •

Alter the system’s environment (e.g., •

change values read from sensors, set CPU and peripheral controllers register values, modify streaming data)

Expedite Problem Reproduction and Resolution

Force the state of the system to •

reproduce the error by altering the system’s environment

Capture a trace of global and local •

variables, function calls, and data during the reproduction of a problem

Timestamp any point in the system to •

determine timing defects and performance

Dynamically Debug Running Software Insert debug code (including logs and •

prints) to isolate defects Insert code to test fixes •

Peek and poke variables, registers, and •

sensors to validate fixes

Modify a running system without having •

to reboot and set up tests for every code change

Force the System to Extreme Conditions

Inject faults at any time during a test •

Force the environment of the device to a •

specific state (e.g., high temperature reading on a sensor)

Log timestamps that quantify the •

performance of any part of the device Set the device to a specific state that •

may only be reached after hours of continuous operation (e.g., buffers full, queues empty)

Eliminate the use of sophisticated test •

equipment (e.g., forcing the hop count to a large value in a data packet)

(9)

Technical Specifications

Workbench Host OS Support Windows XP Professional, Service •

Pack 2, x86

Windows Vista (Business and •

Enterprise), x86

Red Hat Enterprise Linux 4 Workstation, •

Update 5

Red Hat Enterprise Linux Desktop with •

Workstation option 5, x86, or x86-64 Red Hat Fedora Core 7, x86 •

SUSE Desktop Linux 10, •

Service Pack 1, x86

SUSE Linux/openSUSE 10.2, x86 •

Solaris 9, update 9/05 (GTK only) •

Solaris 10 •

Server Host OS Support

Windows XP Professional, Service Pack 2 •

Windows 2000 Professional, Service Pack 4 •

Red Hat Enterprise Linux 3 Workstation, •

Update 6

Red Hat Enterprise Linux 4 Workstation, • Update 3 SUSE Linux 9.3 • Solaris 8 • Solaris 9 • Solaris 10 • Target OS Support VxWorks 6.3, 6.4, 6.5, 6.6 platforms • VxWorks 5.5* •

Wind River Linux 1.4, 1.5, 2.0 based •

platforms

* Core file generation is not supported with VxWorks 5.5. Windows is the only supported host and PowerPC is the only supported target architecture with VxWorks 5.5.

Target Architecture Support ARM/XScale* • IA-32 • MIPS* • PowerPC •

* Not supported with Wind River Linux Most processors within these architec-tures that are supported by the VxWorks or Wind River Linux platforms are also supported in Lab Diagnostics, with some exceptions.

Wind River Software Requirements If Workbench is used, version 3.0 is required. Lab Diagnostics can also be run in a standalone mode that is independent from the Workbench development suite.

Third-Party Software Requirements Apache Ant 1.6.5 or later

Sun JDK 5.0 •

One of the following database servers: •

HSQLDB 1.8.0.9 (installed with

-product)

MySQL database server 5.0.x

-Oracle 9i database server version

-9.2.0.x (with 10g JDBC thin driver) One of the following J2EE application •

servers:

JBoss 4.0.3 SP1 (installed with product)

-BEA WebLogic Platform 9.2

-One of the following FTP servers: •

WFTPD (installed with VxWorks/Linux

-platforms)

FTP server in IIS included in Windows

-3Com 3C server

-Perl Interpreter 5.8.8 or later •

One of the following browsers: •

Internet Explorer 6.x or later

-Firefox 1.5 or later

-Wind River Device Management

Wind River Device Management consists of two interoperable applications that create a powerful, enterprise-wide workflow and information flow: Lab Diagnostics and Wind River Field Diagnostics. Designed for use with Wind River Workbench, these applications enable companies to perform fact-based diagnostics and software fault correction across the entire device life cycle, from development to QA to field support. They are available for VxWorks 5.5, VxWorks 6.x, and Wind River Linux 1.4–2.0 (see Figure 16).

Wind River Field Diagnostics Wind River Field Diagnostics is a scalable, remote diagnostics system that enables support engineers to securely collect and manage deployed device data to diagnose and correct faults. Field Diagnostics is an enterprise-class application that consists of a site configuration for onsite device data aggregation and diagnostics, and an enterprise configuration for device data aggregation from worldwide deploy-ments and remote diagnostics.

The application links device manufactur-ers with device usmanufactur-ers through a secure device data exchange infrastructure. With Field Diagnostics, device manufac-turers can improve device uptime, streamline service operation, reduce service cost, and increase service revenue. This standalone product is tightly integrated with Wind River Workbench and sold as an add-on to

Development Customers

Wind River Lab Diagnostics Wind River Field Diagnostics

Streamlines development and QA processes to deliver higher-quality

devices to market faster

Streamlines the support process to increase device uptime and

device user satisfaction

Quality

Assurance Support

(10)

Wind River platforms. For more informa-tion, see the Field Diagnostics product note.

When using Lab and Field Diagnostics together, developers can do the following:

Access a customer’s server directly from •

their workstation

Import deployed device logs directly •

into Workbench Diagnostics for deep analysis of core files and Sensorpoint logs

Post field-safe Sensorpoints directly to •

Device Management Server, for use by support personnel

This allows effective knowledge-sharing between field, support, and development teams in order to prevent issues and resolve faults quickly.

Partner Ecosystem

Wind River’s world-class partner ecosys-tem ensures tight integration with solutions from a wide range of premier software providers. Our partners extend the capabilities of Wind River Device Management by offering out-of-the-box integration and support for key technolo-gies in a number of fast-moving indus-tries. Our customer support team is trained to troubleshoot partner technolo-gies in use with Wind River products, making ours the most comprehensive and best-supported partner ecosystem in the Device Software Optimization (DSO) industry.

Professional Services

Wind River Professional Services, a CMMI Level 3–certified organization, enables you to reduce risk and focus on develop-ment activities that add value and differentiate your design. Our team delivers device software expertise within structured engagements that directly address key development challenges and contribute to the success of our clients. Our track record of timely delivery and in-depth understanding of market and technology dynamics makes Wind River a

valuable implementation partner for clients worldwide. Based on our commer-cial grade project methodology, service offerings include device design, BSP and driver optimization, software system and middleware integration, and legacy application and infrastructure migration. Wind River Professional Services can configure Wind River Lab Diagnostics to meet your needs by extending processor support, extending target operating system support, validating Lab

Diagnostics on Linux host environments, and integrating agents.

Education Services

Education is fundamentally connected not only to individual performance but to the success of a project or entire company. Lack of product knowledge can translate into longer development schedules, poor quality, and higher costs. The ability to learn—and to convert that learning into improved performance— creates extraordinary value for individu-als, teams, and organizations. To help your team achieve that result, Wind River offers flexible approaches to delivering product education that best fits your time, budget, and skills development requirements.

Support

Wind River provides full technical support for VxWorks 6.x, Wind River Workbench, Wind River Device Management, and Wind River Linux platforms. Our global support organiza-tion is staffed with engineers who have extensive experience with Wind River products and device software develop-ment. At major support centers world-wide, our local experts can help diagnose problems, provide guidance, or answer “How do I…?” questions. Support is also available 24 hours a day at our Online Support website (www.windriver.com/support) or by email at [email protected].

Visit Wind River Online Support for fast access to product manuals, download-able software, and other problem-solving resources. Additional features, including patches and technical tips for common problems, are available for all customers on subscription. Online Support visitors can also access a community of develop-ers to discuss their issues and experiences. If you cannot find the information you need through Online Support, please contact our global support team.

North America, South America, and Asia/Pacific [email protected] Toll-free: 800-872-4977 (800-USA-4WRS) Tel.: 510-748-4100 Fax: 510-749-2164 Hours: 6:00 a.m.–5:00 p.m. (PST) Japan [email protected] Tel.: +(00)81-3-5778-6001 Fax: +(00)81-3-5778-6003

Hours: 9:00 a.m.–5:30 p.m. (local time)

Europe, the Middle East, and Africa [email protected] Toll-free: +800 4977 4977 France tel.: +33 1 64 86 66 66 France fax: +33 1 64 86 66 10 Germany tel.: +49 899 624 45 444 Germany fax: +49 899 624 45 999 Italy tel.: +39 011 2448 411 Italy fax: +39 011 2448 499

Middle East Region tel.: +972 9741 9561 Middle East Region fax: +972 9746 0867 Nordic tel.: +46 8 594 611 20

Nordic fax: +46 8 594 611 49 UK tel.: +44 1793 831 393 UK fax: +44 1793 831 808

References

Related documents

D) di diff ffere erent c nt co# o#pou pound nds it s ith di h diff ffer eren ent co# t co#po posit sitio ions ns Ans: B. Ans:

First, the point at which peak oral air flow occurred was clearly identifiable as being within the consonant phoneme and could be measured reliably; second, this point served as

Poster presented at the 12th Biennial Conference of the Society for Community Research and Action, Montclair, NJ, USA..

6.3.1.1 Conversion to a Roux-en-Y Gastric Bypass or Biliopancreatic diversion with duodenal switch may be considered for members who have not lost of more than 50% of their

• The purpose of this session is to explain the success factors in physician compensation models for hospital employed and independent medical groups?. Additionally, we will

Physical Resources Service Orchestration SaaS/ CaaS PaaS IaaS NaaS.. Management Security & Privacy Cloud Operational Function Cloud Availability Function Monitoring &

Therefore, the objective of the present study was to investi- gate ovarian function in women of childbearing age who were HCV+ and to relate these findings with the women’s

**Note – anytime a new email account is added to Hosted Exchange the customer domain must be re-added; domain must be removed when email account is successfully added.**.