The aim of the project: This project aims to develop a Ride by Wire control unit prototype to be installed on motorcycles (scooters) in order to keep under control a 4-cylinder gasoline engine with at least 125 cc.

Ride by Wire term, derived from automotive applications (Drive by Wire) and yet before from aerospace ones (Fly by Wire), denotes substantially a subjugation of the throttle valve position in the manifold of internal combustion engine through an electric motor. Furthermore, the enslavement is mainly influenced by the accelerator knob or pedal position but also by other criteria not directly set by the user. This latest feature makes Ride by Wire units predisposed to the implementation of sophisticated engine control strategies with such objectives as , for example: improvement of driving performance through partial compensation of torque response; possibility to implement traction control system more efficient than any conventional one; reduction of fuel consumption; improvement of motor starts and of idle speed control.

The main feature that distinguishes this prototype from other Ride by wire control units on sale regards its unity and a substantial cost reduction. In particular, the type of unit to be developed is mechanical, integrated to the throttle body that reduces the overall volume and, at the same time, complicates the system architecture design due to increased mechanical stresses to which the control unit is subject to.

In the plant, where the project is held, the common practice is to design two distinct types of a unit for the same project: the first is dedicated to the development phase and to software integration tests, while the second one is aimed to the production of a series representing the real result of the design. In the development version, the main microcontroller is not located on the main board of the control unit but is interfaced to the unit via MEB (Memory Emulation Board). The MEB is able to emulate, via RAM, a FLASH bench which, in the produced unit, is mostly dedicated to the calibration parameters storage. In this way, it is possible to easily modify each parameter by using a laptop computer interfaced to the MEB via CAN bus, without recompiling the whole project because of new calibrations and, later on, to restart the control unit and to reload, remotely, a new software image

It should be noted that, unlike most of the projects concerning the engine control unit, the mechanic one requires a completely different layout and housing as we consider a development version or a production one. Therefore, system testing becomes more complicated. The development control unit, indeed, is more cumbersome and delicate (due to MEB) respect to the production version; it may not be integrated into the throttle body also because during the software testing the unit must be located so as is would be easily accessible by service personnel. For these reasons, unlike the production version, the development unit consists of two distinct parts:

• the main block which includes the main board and the MEB, placed in an easily accessible location where information is being processed and stored
• a dummy module integrated in the throttle body and connecting the main block of the controller to the electric motor that drives the throttle

Activities carried out for the software project development

The Finsoft consulting concerned the porting of some software modules, written in C, to the Ride by Wire control unit architecture under development. These modules were designed for units having different hardware configuration - both for a main microcontroller type and for a number of custom peripheral devices and custom circuits. Besides, in most cases the modules were associated with Bowden projects (in which unlike Ride by Wire, the throttle valve position is mechanically connected to the wheel or to the accelerator pedal). It is important to emphasize that the software architecture of the new unit differs from the previous ones, owing to the clearer vertical separation of the layer code (basically referred to as BIOS, Base and Application) and to the manner, in which data structures and functions addressing to other modules (especially those belonging to another layer), should be protected or exported.

The implementation specifications, based on the type of a module to be ported, were prepared by PJLS (Project Leader Software) or by SDE department (System Deployment Engineering), that represent the center of business development of algorithms and strategies for engine control. Consulting activities concerned the new software modules implementation and the preparation of functional and implementation specifications. Some part of the documentation is considered to be Confidential within the enterprise while the other one is addressed to the customer that commissioned R&D of the Ride by Wire mechanical control unit.

The activities, regarding preparation of specifications, development and testing of implemented software modules and report generation, were planned, executed and completed according to the software development process model described by the automotive SPICE ® standard, chosen by the Company.

The tools mainly used were:

• Telelogic Change ®: to publish and assign software developers new features to implement and change requests regarding non-compliance of the results (bug fixing). Moreover, this tool allows to control the application lifecycle and to track changes made to the project, grouping them according to macro activities performed on various modules
• Telelogic SYNERGY ®: to control the software project configuration . This tool is integrated (co-built) into the previous one
• Cross-compilation toolchain Altium Tasking ®: to support the process of compiling and creating of executable files; the target is a microcontroller compatible with the C166 architecture. This toolset allows to convert an .exe file into "IEEE" (useful when debugging), "Motorola S-Record" and "Intel HEX" formats
• Lauterbach ® Emulator for ST10 microcontrollers
• Matlab / Simulink ® environments and Stateflow ® toolbox: necessary to design control algorithms and to conduct a subsequent validation phase. The expected results obtained from simulation are compared with those actually gathered during the test. This environment is also essential for creating of requirements necessary for the software implementation phase
• Dspace TargetLink ®: for automatic code generation (to be integrated manually into the software project) from Matlab / Simulink / Stateflow ® models

Related Customers

We worked with much success for some of our Clients.