Search Results

The Electro Gyro-Cator allows a driver to monitor his progress, plot and follow courses to a destination, select alternate routes, and drive more safely on unfamiliar roads or at night. Employing a sealed helium gas-rate gyro, the Electro Gyro-Cator offers visual display (CRT display) of a car's present location, direction and route, with overlay maps for fast, simple route selection and monitoring. The primary elements of the unit include trip and direction sensors, a 16-Bit central processing unit, a CRT display screen and a collection of transparent overlay maps fitted to the screen.

Electronic control units (ECUs) offer a modular, networked approach to real time machine control and diagnostics. Software embedded in these controllers offer agile and customizable solutions because of the intimate relationship with the ECU hardware and its inputs/outputs. In an idealistic view, embedded software should support the machine's life - 30 years or longer. Developing and maintaining software for these systems requires a strategy. A framework demonstrating common building blocks and long-term centralized support for ECUs on a machine is presented. This strategy reduces the detailed knowledge of the specific machine controls needed by ECU developers and provides the components and infrastructure key to extending the life and functionality of the ECU.

This SAE Standard specifies a message set, and its data frames and data elements specifically for use by applications intended to utilize the 5.9 GHz Dedicated Short Range Communications for Wireless Access in Vehicular Environments (DSRC/WAVE, referenced in this document simply as “DSRC”), communications systems. Although the scope of this Standard is focused on DSRC, this message set, and its data frames and data elements have been designed, to the extent possible, to also be of potential use for applications that may be deployed in conjunction with other wireless communications technologies. This Standard therefore specifies the definitive message structure and provides sufficient background information to allow readers to properly interpret the message definitions from the point of view of an application developer implementing the messages according to the DSRC Standards.

It is well known that backpressure is one of the important parameters to be minimised during the exhaust system development. Unfortunately, during the first phases of an engineering process of a new engine, engine prototypes are not available yet. Due to this the exhaust system backpressure is generally evaluated using simulation software, and/or measuring the backpressure by a flow rig test at room temperature. Goal of this paper is to compare exhaust backpressure results obtained respectively: i) at the room temperature flow rig; ii) at the engine dyno bench; iii) by simulation with one of the most common 1D fluidodynamics simulation tool (Gt-Power). A correlation of the three different techniques is presented.

Model-based software development is a well-established software development process and recognized by ISO26262 [1] as allowing for highly consistent and efficient development. Nevertheless, enhancing a model-based development process in such a way that it is compliant with the ISO26262 safety standard is a challenging task. To achieve ISO26262 compliance, the development team of a safety-related software project faces a multitude of additional requirements for the development process without a corresponding increase of the project budget to fulfill them. The fact that many of the requirements of ISO26262 are defined in a very generic way such that an interpretation is required further hampers their implementation. We propose a 10-step strategy to achieve an ISO26262 compliant model-based software development process. This strategy relates ISO26262 requirements with state-of-the art methods and approaches currently used for model-based software development.

System requirements and Interface Control Drawings (ICDs) make a variety of demands for MIL-STD-1553 remote terminals (RTs). Among these requirements are the need to ensure data integrity and sample data consistency, the need to perform bulk (multi-message) data transfers, and the need to offload the operation of the host CPU to the greatest degree possible. This latter requirement is reflected in such specifications as CPU spare bandwidth. The latest 1553 terminals provide a variety of choices for performing the different types of transfers. This paper provides a discussion of the hardware and software techniques for achieving these objectives. Three different schemes for RT subaddress memory management are presented: single message, circular buffer, and double buffered. For receive and transmit messages, these include fully synchronous single message transfers, asynchronous single message transfers, and multi-message transfers.