The AUTOSAR organization was established in 2003, mainly by European car manufacturers, component suppliers, and other electronics, semiconductor, and software system companies. It is committed to developing an open, standardized software architecture for the automotive industry. The goal is to "cooperate on standards and compete on applications", so can improve the stability of the basic platform, reducing costs, and enhancing the quality and speed of controller product development. The 2.1 version of the specification was released at the end of 2006, and the 3.1 version was released in 2008. Functional safety, Ethernet, and other contents are also added. Currently, the widely used versions are 4.2.1 and 4.2.2, as well as version 4.3.1.

In the major trends of electrification, connectivity, and intelligence, the number of automotive electronic and electrical components is increasing. The electrical structure is becoming more complex, and the development cycle of the vehicle is continuously shortening. Basic software plays an increasingly important role.

ZC has the core technology of the AUTOSAR basic software and can provide on-site support with high quality, fast speed, and low cost.

Product Feature

Ø  Compliant with AUTOSAR 4.3.1

Ø  ARTOP configuration tool, compatible up to AUTOSAR 4.4.0

Ø  Operating System

Ø  Communication Protocol Stack（CAN\LIN）

Ø  Diagnostic Protocol Stack (UDS\J1939)

Ø  Network Management (OSEK\AUTOSAR）

Ø  Calibration Protocol Stack（XCP\CCP）

Ø  Storage Protocol Stack

Ø  Custom Development of Complex Drivers

Ø  Engineering Services

Introduction to CANFD MCAL Feature

The CANFD MCAL complies with the AUTOSAR 4.3.1 version and can support CAN FD messages with a maximum of 64 bytes. It can achieve a rate of 1 Mbit/s in CAN mode and 2 Mbit/s in CANFD mode. Message objects can be configured to receive standard frames with an 11-bit identifier or extended frames with a 29-bit identifier, or to receive both standard and extended frames simultaneously. They can also be grouped into different priority classes for transmission and reception.

l  Sending Function

When transmitting CANFD data, the Can_Write() function is called to request the transmission of CANFD messages. Once the data transmission of CANFD is completed, a transmission interrupt is triggered to notify the upper layer module for subsequent operations.

l Receiving Function

When receiving data frames transmitted on the CANFD bus, a receive interrupt is triggered to execute the Can_IsrReceiveHandler() function. This function checks the received CANFD data frames, parses the extracted data, and converts it into a readable format by the controller or processor, and storing it in the Can_RxMessageData Buffer.

l  Interrupt Handling

CANFD interrupts can be used to handle the following events:

Receive Interrupt: When a new message is received on the CANFD bus, the controller generates a receive interrupt and enters the receive interrupt handling function Can_Isr ReceiveHandler(). It processes the reception event and wake-up event, and calls the CanIf_RxIndication() notification function.

Error Interrupt: When an error occurs on the CAN FD bus, such as an erroneous frame or bus error, the controller generates an error interrupt to allow the processor to handle it promptly.

Transmit Interrupt: When the data transmission on the CAN FD bus is completed, the controller generates a transmission interrupt and enters the transmit interrupt handling function Can_IsrTransmitHandler(). It processes the frame transmission success event and calls the CanIf_TxConfirmation() notification function, allowing the processor to proceed with subsequent operations.

l  FIFO Function

FIFO is used to prevent the loss of incoming messages (Receive FIFO) and to minimize the setup time for outgoing messages (Transmit FIFO). The FIFO structure can also be used to automatically receive or transmit a series of CAN messages, and generate a single message interrupt after the entire CAN frame is completed.

ZC.MuNiu provides a comprehensive basic software platform solution for the development of automotive electronic control units. This product refers to international standards such as AUTOSAR and OSEK, and has configuration tool based on the AUTOSAR ARTOParchitecture.  ZC.MuNiu supports communication, diagnostics, and network management specifications for major OEMs like SAIC, FAW, Geely, GAC, CCAG, and GWM. ZC.MuNiu mainly includes: operating system, communication protocol stack (CAN/LIN), diagnostic protocol stack (UDS/J1939), network management (OSEK/AUTOSAR), calibration protocol stack (XCP/CCP), storage protocol stack, complex driver modules, etc. ZC.MuNiu also provide bootloader update program and configuration tool, which can be configured and redeveloped according to customer requirements. While providing basic software products, ZC also offers development services for the implementation of controller basic software functions.

The safety level of Infineon TLE989x is ASIL B, with 32-bit Arm Cortex-M3 core, up to 60MHz.  TLE989x supports Arm Cortex-M3 kernel operating system. ZC can provide basic software products that comply with ASPICE Level2 processes and functional safety ASIL B requirements based on the Infineon TLE989x.

ZC.MuNiu Basic Software Platform can be applied to the development of automotive electronic control unit products using the Infineon TLE989x series of chips.

For example:

Ø  Automotive Electronic Water Pump Controller

Ø  Engine Cooling Fan Controller

Ø  Sliding Door Controller

Ø  Car Door Lock Controller

Ø  Car Sunroof Controller

Ø  Air Conditioning Controller

MUNIU SOFTWARE COPYRIGHT REGISTRATION CERTIFICATE

Click to download the product manual