Browse Topic: Communication protocols
Recent advancements in energy efficient wireless communication protocols and low powered digital sensor technologies have led to the development of wireless sensor network (WSN) applications in diverse industries. These WSNs are generally designed using Bluetooth Low Energy (BLE), ZigBee and Wi-Fi communication protocol depending on the range and reliability requirements of the application. Designing these WSN applications also depends on the following factors. First, the environment under which devices operate varies with the industries and products they are employed in. Second, the energy availability for these devices is limited so higher signal strength for transmission and retransmission reduces the lifetime of these nodes significantly and finally, the size of networks is increasing hence scheduling and routing of messages becomes critical as well. These factors make simulation for these applications essential for evaluating the performance of WSNs before physical deployment of
Nowadays, Software-in-the-Loop (SIL) represents a crucial methodology in the development and validation of control systems, particularly in sectors such as automotive, marine, and aerospace. It involves creating a virtual representation of a real environment with varying levels of accuracy. Using SIL techniques, engineers can develop and test software in the early stages of the development cycle, reducing overall time-to-market and costs. Typically, to simulate complex control systems, a primary tool is used to manage and integrate an entire application-specific environment composed of application software, plants, sensors and actuators, and communication protocols. Although several commercial solutions are currently available on the market to support SIL activities, Dumarey Softronix wanted to explore the possibility of developing an in-house software tool to leverage the benefits of SIL. This paper provides a high-level overview of the main steps involved in developing a complete SIL
The rapid evolution of electric vehicles (EVs) necessitates advanced electronic control units (ECUs) for enhanced safety, monitoring, and performance. This study introduces an innovative ECU system designed with a modular architecture, incorporating real-time monitoring, cloud connectivity, and crash sensing. The methodology includes cost-effective design strategies, integrating STM32 controllers, CAN bus systems, and widely available sensors for motor RPM and temperature monitoring. Key findings demonstrate that the proposed ECU system improves data reliability, enhances vehicle safety through crash response systems, and enables predictive maintenance via cloud connectivity. This scalable and affordable ECU is adaptable to a broad range of EV models.
This SAE Aerospace Recommended Practice (ARP) describes terminology specific to unmanned systems (UMSs) and definitions for those terms. It focuses only on terms used exclusively for the development, testing, and other activities regarding UMSs. It further focuses on the autonomy and performance measures aspects of UMSs and is based on the participants’ earlier work, the Autonomy Levels for Unmanned Systems (ALFUS) Framework, published as NIST Special Publication 1011-I-2.0 and NIST Special Publication 1011-II-1.0. This Practice also reflects the collaboration results with AIR5665. Terms that are used in the community but can be understood with common dictionary definitions are not included in this document. Further efforts to expand the scope of the terminology are being planned.
Researchers have created a 98-milligram sensor system — about one tenth the weight of a jellybean or less than one-hundredth of an ounce — that can ride aboard a small drone or an insect, such as a moth, until it gets to its destination. Then, when a researcher sends a Bluetooth command, the sensor is released from its perch and can fall up to 72 feet — from about the sixth floor of a building — and land without breaking. Once on the ground, the sensor can collect data, such as temperature or humidity, for almost three years.
Increasing digitalization of the aircraft cabin, driven by the need for improved operational efficiency and an enhanced passenger experience, has led to the development of data-driven services. In order to implement these services, information from different systems is often required, which leads to a multi-system architecture. When designing a network that interconnects these systems, it is important to consider the heterogeneous device and supplier landscape as well as variations in the network architecture resulting from airline customization or cabin upgrades. The novel ARINC 853 Cabin Secure Media-Independent Messaging (CSMIM) standard addresses this challenge by specifying a communication protocol that relies on a data model to encode provided and consumed information. This paper presents an approach to integrate CSMIM-specific communication concepts into a Model-Based Systems Engineering (MBSE) framework using the Systems Modeling Language (SysML). This enables a streamlined
IEEE-1394b, Interface Requirements for Military and Aerospace Vehicle Applications, establishes the requirements for the use of IEEE Std 1394™-2008 as a data bus network in military and aerospace vehicles. The portion of IEEE Std 1394™-2008 standard used by AS5643 is referred to as IEEE-1394 Beta (formerly referred to as IEEE-1394b.) It defines the concept of operations and information flow on the network. As discussed in 1.4, this specification contains extensions/restrictions to “off-the-shelf” IEEE-1394 standards and assumes the reader already has a working knowledge of IEEE-1394. This document is referred to as the “base” specification, containing the generic requirements that specify data bus characteristics, data formats, and node operation. It is important to note that this specification is not designed to be stand-alone; several requirements leave the details to the implementations and delegate the actual implementation to be specified by the network architect/integrator for a
This Handbook is intended to accompany or incorporate AS5643, AS5643/1, AS5657, AS5706, and ARD5708. In addition, full understanding of this Handbook also requires knowledge of IEEE-1394-1995, IEEE-1394a, and IEEE-1394b standards. This Handbook contains detailed explanations and architecture analysis on AS5643, bus timing and scheduling considerations, system redundancy design considerations, suggestions on AS5643-based system configurations, cable selection guidance, and lessons learned on failure modes.
The SAE Aerospace Information Report AIR5315 – Generic Open Architecture (GOA) defines “a framework to identify interface classes for applying open systems to the design of a specific hardware/software system.” [sae] JAUS Service (Interface) Definition Language defines an XML schema for the interface definition of services at the Class 4L, or Application Layer, and Class 3L, or System Services Layer, of the Generic Open Architecture stack (see Figure 1). The specification of JAUS services shall be defined according to the JAUS Service (Interface) Definition Language document.
This document defines a set of standard application layer interfaces called JAUS Manipulator Services. JAUS Services provide the means for software entities in an unmanned system or system of unmanned systems to communicate and coordinate their activities. The Manipulator Services represent platform-independent capabilities commonly found across domains and types of unmanned systems. At present, twenty-five (25) services are defined in this document. These services are categorized as: Low Level Manipulator Control Services – The one service in this category allows for low-level command of the manipulator joint actuation efforts. This is an open-loop command that could be used in a simple tele-operation scenario. The service in this category is listed as follows: Primitive Manipulator Service Manipulator Sensor Services – These services, when queried, return instantaneous sensor data. Three services are defined that return respectively joint positions, joint velocities, and joint
The added connectivity and transmission of personal and payment information in electric vehicle (EV) charging technology creates larger attack surfaces and incentives for malicious hackers to act. As EV charging stations are a major and direct user interface in the charging infrastructure, ensuring cybersecurity of the personal and private data transmitted to and from chargers is a key component to the overall security. Researchers at Southwest Research Institute® (SwRI®) evaluated the security of direct current fast charging (DCFC) EV supply equipment (EVSE). Identified vulnerabilities included values such as the MAC addresses of both the EV and EVSE, either sent in plaintext or encrypted with a known algorithm. These values allowed for reprogramming of non-volatile memory of power-line communication (PLC) devices as well as the EV’s parameter information block (PIB). Discovering these values allowed the researchers to access the IPv6 layer on the connection between the EV and EVSE
In the automotive industry, the zonal architecture is a design approach that organizes a vehicle’s electronic and communication systems into specific zones. These zones group components based on their function and physical location, enabling more efficient integration and simplified communication between the vehicle’s various systems. An important aspect of this architecture is the implementation of the Controller Area Network (CAN) protocol. CAN is a serial communication protocol developed specifically for automotive applications, allowing various electronic devices within a vehicle, such as sensors, actuators, and Electronic Control Units (ECUs), to communicate with each other quickly and reliably, sharing information essential for the vehicle’s operation. However, due to its limitations, there is a need for more efficient protocols like Automotive Ethernet and Controller Area Network Flexible (CAN FD), which allow for higher transmission rates and larger data packets. To centralize
The term Software-Defined Vehicle (SDV) describes the vision of software-driven automotive development, where new features, such as improved autonomous driving, are added through software updates. Groups like SOAFEE advocate cloud-native approaches – i.e., service-oriented architectures and distributed workloads – in vehicles. However, monitoring and diagnosing such vehicle architectures remain largely unaddressed. ASAM’s SOVD API (ISO 17978) fills this gap by providing a foundation for diagnosing vehicles with service-oriented architectures and connected vehicles based on high-performance computing units (HPCs). For service-oriented architectures, aspects like the execution environment, service orchestration, functionalities, dependencies, and execution times must be diagnosable. Since SDVs depend on cloud services, diagnostic functionality must extend beyond the vehicle to include the cloud for identifying the root cause of a malfunction. Due to SDVs’ dynamic nature, vehicle systems
This SAE Technical Information Report (TIR) establishes the instructions for the documents required for the variety of potential functions for PEV communications, energy transfer options, interoperability, and security. This includes the history, current status, and future plans for migrating through these documents created in the Hybrid Communication and Interoperability Task Force, based on functional objective (e.g., [1] If I want to do V2G with an off-board inverter, what documents and items within them do I need, [2] What do we intend for V3 of SAE J2953, …).
Items per page:
50
1 – 50 of 981