Hitachi, Ltd.

Hitachi Automotive Systems, Ltd.

Sujit S Phatak

Heming Chen

Yuan Xiao

Donald James McCune

Can Wang

Sanketh Shetty

Yasuhiro Ito

George Saikalis

Yasuo Sugure

Nikhil Seera

Ichiki Homma

Herning Chen

Deepak Ramaswamy

Example implementations described herein are directed to an embedded edge device and edge/cloud system configured to facilitate seamless connectivity between multi-domain assets for system of system and internet of everything applications. Through the use of a novel horizontally scalable embedded architecture for embedded edge device that can be connected to multi-domain assets to enable seamless connectivity between them, the example implementations can facilitate wireless connections across multi-domain assets to allow overall system of systems and internet of everything applications to improve quality of life.

Horizontal embedded architecture for system of systems (SoS) and internet of everything (IoE)

In some examples, one or more computing devices on a network may receive, from a client computing device, one or more inputs for configuring a simulation, the simulation including at least a first simulator and a second simulator. The one or more computing devices may allocate computing resources including at least a first virtual machine for executing at least one of the first simulator or the second simulator. The one or more computing devices may configure a first simulation controller executable on the first virtual machine for controlling execution of the at least one of the first simulator or the second simulator. The first simulation controller may initiate execution of at least one of the first simulator or the second simulator as part of execution of the co-simulation. In some examples, a result of the co-simulation may be sent to the client computing device.

Simulation including multiple simulators

Example implementations described herein are directed to systems and methods that include the storage of I/F communication activity during a co-execution and a repeater to reproduce such I/F communication activity. Thus in a subsequent re-execution of the simulation or applications, one or more of the simulations or applications utilized can be replaced with a repeater without requiring the full execution of the simulation or application, thereby saving license usage as well as requiring fewer hardware resources for execution.

Co-simulation repeater with former trace data

Example implementations described herein facilitate an interactive environment for companies and personals to validate and develop autonomous driving systems. Such implementations apply to, but are not limited to, applications such as sensor data collection for deep learning model training; validation and development of various detection algorithms; sensor fusion (e.g., radar, lidar, camera) algorithm development and validation, trajectory/motion planning algorithm validation; and control algorithm validation.

Online self-driving car virtual test and development system

In some examples, a system may receive, over a network from a vehicle computing device onboard a vehicle, sensor data for at least one sensed parameter of a vehicle component. The system may determine, based on the sensor data, a damage result indicative of fatigue damage to the vehicle component. Based at least partially on the damage result, the system may send a communication to at least one of the vehicle computing device onboard the vehicle, or a computing device associated with an account associated with the vehicle. In some cases, the damage result may be determined from at least one of accessing a lookup table using the sensor data, or executing a fatigue simulation using sensor data.

Vehicle component failure prevention

In some examples, a processor on a vehicle may determine, based at least partially on information obtained from a sensor, that a fuel level of the vehicle is increasing. Further, the processor may determine that the fuel level has stabilized for a threshold time. In addition, the processor may determine an amount of fuel added to the vehicle, and may send, over a wireless network to a computing device, a communication indicating the amount of fuel added. In some cases, the computing device may compare the amount of fuel indicated in the communication from the processor with an amount of fuel indicated in information received from a point-of-sale device for determining a difference.

Fuel measurement for fleet vehicles

Apparatus for providing real-time data to a hardware-in-the-loop simulator for an automotive vehicle. The apparatus includes a test vehicle having at least one sensor which generates an output signal representative of a condition of the vehicle. A wireless transmitter such as a cellular phone on the motor vehicle receives the sensor output signal as an input signal and transmits that output signal to a computer network. A simulator data server receives the data from the computer network and provides that data to the hardware-in-the-loop simulator.

Apparatus for providing data to a hardware-in-the-loop simulator

A system and method for allocating software resources. Multiple tasks are received from a network in which each task requires at least one software resource. Each task is analyzed to determine the type of resource(s) required to execute each such task. The availability of the software resource(s) is determined and, if available, allocated to the requesting task. If the software resource(s) is not available, the task is stored in a queue until the software resource(s) becomes available.

Virtual resource management tool for cloud computing service

A control system for a vehicle having a plurality of subsystems in which each subsystem includes a sensor and/or actuator. A general purpose processor is programmed with a plurality of software applications in which each software application is associated with one of the vehicle subsystems. The subsystems and processor communicate with each other through an electrical bus and each subsystem includes a communication interface to receive commands from the processor as well as to send task signals to the processor. A task arbitrator prioritizes the order of execution of multiple task signals received by the processor during a preset time period. The general purpose processor then initiates execution of the software application associated with the subsystem of the sensor signal received from the task arbitrator and thereafter transmits a control signal to one or more of the subsystems via the bus as a result of execution of the associated software application.

Control system for an automotive vehicle

A method for identifying a value of an unknown circuit component for an analog signal having a known output profile in which a simulation list of the analog circuit is first created including the component with the unknown value. A transfer function for the known output value is then created using a programmed processor and the transfer function is then solved by the processor for the value of the unknown component. For nonlinear circuit components, a linear model is substituted for the nonlinear components prior to creating the simulation list.

Method of identifying a value of an unknown circuit component in an analog circuit

A method for the co-simulation of two or more interacting mathematical models in which each model has at least one input port and one output port for inputting and outputting values of parameters in a predefined parameter protocol. The unit of measurement is identified for each parameter in the model and a scaling factor is then generated to equalize the units of measurement for each parameter in each model. The parameter protocol for each port is then determined and a virtual bus with unique locations is configured for each parameter in the models. The parameters from the models are then configured as a function of the parameter protocol so that the same parameters from different models are associated with the same location in the virtual bus.

Method for co-simulation of two or more mathematical models

A system for managing electrical power requirements between at least two power grids including a number of automotive vehicles each of which has an electric motor which propels the vehicle at least partly during its operation. An electric battery is contained in each vehicle as well as a wireless transmitter. A processor contained within each vehicle communicates with the wireless transmitter to transmit information to a base station indicative of the state of charge of the battery, vehicle identification information, and vehicle destination. The base station or upstream entity processes the data from the multiple vehicles to estimate the geographic power requirements necessary to recharge the batteries and then redirects power among at least two different power grids in order to meet those geographic power requirements.

System for managing electrical power distribution between infrastructure and electric vehicles

A method and apparatus for developing multicore microcomputer-based systems. A dual core controller model having at least one parameter is simulated and, similarly, a plant model having at least one parameter and controlled by the controller model is also simulated. The user interface then has access to the parameters of the controller model and plant model and optionally suspends execution of the controller model and plant model in response to a trigger event. The user interface determines the status of the various controller model parameters for both cores and/or plant model parameters at the time of the trigger without altering the controller model parameters or the plant model parameters. The core parameters for both cores are displayed on a display device.

Growing community of inventors

Farmington Hills, MI, United States of America

Sujit S Phatak