Stéphane Louvet

Dr Mouham Tanimou

MDX and AUTOSAR Standards for Model Sharing to leverage Tier1 -OEM cooperation in the ECU software development

Keywords: Engine Control, embedded software, Model Based Design, Software Sharing, Model Sharing, MDX, AUTOSAR, automatic code generation, ASCET, Simulink®

Motivation

Software Sharing in automotive embedded software development has continuously grown over the last decades and is still getting more importance and attention. Main advantages for Software Sharing, as seen by the OEM, are acceleration of development time and cycle as well as a full flexibility to customize the final product, with introduction of its own software. Although classic software sharing has shown its capabilities in practice, it shows some limitations and need to be extended in order to cover additional use cases. The concept of model sharing can help to address those use cases, the following paper outlines the use of ASAM-MDX and AUTOSAR standards with the model sharing to enhance customer cooperation.

Introduction

An increasing number of car manufacturers develop their own functionalities and/or their own software platform in order to communize functions across several control units supplied by different Tier 1 companies. This happens in general as stub-software -already compiled -to be integrated in the final Software. This proven process in practice needs however to be improved and can thus be enhanced to increase development efficiency. In order to achieve such goals, OEMs need the ability to test enhanced or newly developed functions in a very early stage of development, those function checks need to be performed continuously along the V-Cycle development up to the final software. Model Based Design is a general accepted mean to do this and is becoming widespread in the automotive industry. Within the automotive industry, modeling-tools like Simulink® (together with Embedded Coder or TargetLink® as code generators) and ASCET are widely used by OEMs to verify their functions in an early phase using virtual and/or rapid prototyping methodologies. The so verified model together with the achieved data specification can then be exchanged with suppliers as executable specification for functions to be integrated in the ECU; this is one side of the medal of what is called "Model Sharing" at Bosch. The other side of the same medal consists of provision of a development environment for simulation as well as for software build, together with a set of common modeling guidelines and libraries and common data description standard for further development. This approach has a high degree of flexibility, since it provides a framework for OEMs starting from the scratch, but also allow to adapt the derived Process, Method and Tools to car manufacturers having their own approaches. Bosch has established with this approach a five-level classification for model Sharing between Tier1 and OEM, which starts from "Use of ECU virtualization environment" and goes up to "Joint Development". Use of Standards for the data description (e.g. ASAM with -MDX, CDF …and/or AUTOSAR with service libraries, methodology …) as well as standardized interfaces specifications (e.g. as published with AUTOSAR R4.x) can significantly increase the effectiveness of this approach; e.g. by easing labels data management and exchange between development partners through a database (e.g. Visu IT!-ADD), as well as exchange of models. The use of standard for data description with the approach described above raises following central questions that are subject to further analysis in this paper:

-How can standards be used with ECU Software development tools? -What are the constraints on modelling pattern? -How can migration of models be handled/managed between different standards? In this paper we will present a rough description of benefits coming with the standards ASAM-MDX and AUTOSAR with respect to mutual development cooperation. Furthermore, we will focus also on their deployment with modeling tools; the technical aspect to ensure a seamless migration from MDX to AUTOSAR standard will be also described. Some of the results as well as benefits achieved with these standard in customer cooperation within series projects will also be presented.

Model-Sharing

Model-Sharing is a way of exchanging models and model artefacts in order to ease Software development and cooperation between two or several partners; it is part of our Model Based Software Development framework in the ECU development domain. It is also a way to allow rapid prototyping as well as simulation. Basically, motivations for Model Sharing in embedded SW development process are:

-OEM focuses on physical modeling, simulation and rapid prototyping. The OEM can also, via model exchanges, take benefit from supplier physical modeling and simulation know-how. -The supplier is in charge of industrialization of provided models as well as code generation from these models.

Provided models (In general in form of ASCET, Simulink® or TargetLink® models) by the OEM can be used as executable specifications for Software development by the supplier. Using a common tool with it a common language, and standardized files by the development partners for modeling leads to reduction of the amount of to be exchanged documents, and thus enhance the understanding of OEM requirements by the suppliers. This can significantly lead also to reduction of development effort and development time as well as delays in the development.

Typical use cases for Model Sharing are described in the sections below.

Use case 1: OEM describes the expected functionalities in customer specific functions developed by the supplier -the desired changes can be implemented directly in the model -Simulation/Rapid Prototyping can be carried out w/o waiting for an "official" SW release Use case 2: OEM develops its owns model and the supplier is in charge of the "so-called" industrialization of the code -This corresponds to the so-called "Commissioned Development" in Bosch process development -The code implementation is simplified if both partners are working with the same modeling environment (examples : ASCET, Simulink®, TargetLink®) -Functionalities can be tested with Rapid/virtual Prototyping before delivery to the supplier -corrected (enhanced) model can be delivered back to the OEM: This helps to avoid additional traceability documents and minimize risk of forgotten improvements in own model

Cooperation levels

Since each customer has its own dedicated development process, it has therefore specific requirements for development cooperation with suppliers. On the other hand, suppliers need to classify the requests of OEM to find a common approach. Following this line of thought a five-level classification for model Sharing between Tier1 and OEM has been performed at Bosch: from "Use of ECU virtualization environment" up to "Joint Development" [3]. This build a base for discussions with OEMs before starting a new project and it provides a framework for development methodology and contracting. The cooperation usually contains aspects of different types of contracts like service or licensing contract. However, these aspects are typically covered by one agreement describing the complete scope of the cooperation.

Figure 1 -Different cooperation levels for model sharing

The picture below illustrates those cooperation levels in a contracting and process flow view

Figure 2 -Workflow for Model Sharing and contracting

Some of the cooperation models will be shortly described hereafter to better understand the use cases which are addressed in this paper.

Level 0: Virtual Prototyping

Since several years, it can be observed that the trend for ECU software engineering is moving towards PC simulation in order to 1) Save costs by increased development productivity and 2) Manage complexity and apply holistic engineering approaches.

3) Allow different development speed between HW, mechanics and SW And OEM are requesting from Tier1 supplier a stringent support of development cycle oriented usecases at OEM in a virtual manner. This requires to build a virtual test bench, which contains virtual engine ECU-Software (as it is running in the real ECU) as well as representative plant models in a virtual environment, which are real time capable. For the virtual test bench, PC-executable ECU-functions in a powerful simulation environment are then needed [1] [2].

Level 1: Processing of OEM Model

This level of model based cooperation is the so called "Commissionedd Development" within the development process at Bosch; the OEM delivers a (simulatable) model that has to be processed by the Tier1 supplier to generate production code without any change on the model. Alternatively, the OEM can also deliver a specification (e.g. PDF-document) and the supplier creates a model according to this specification. This model will then be delivered to the OEM for further development. Using same modeling tool by the OEM and the Tier1 supplier helps to avoid converting the model to another modeling environment.

Level 2: OEM Model Enhancement and Processing

This model sharing cooperation level is also considered as part of the development process "Commissioned Development" at Bosch. The OEM delivers a model and the Tier1 supplier can introduce non-functional necessary modifications in the model for several purposes, such as:

-optimisation for production code generation -model corrections in case of mistakes found during model implementation -specific interfaces e.g. for diagnostic In comparison to cooperation Level 1, the final model contains added value introduced by the Tier1 supplier to the original the OEM model. Furthermore the development efficiency is getting enhanced, since the modified model by the supplier could be redelivered to the OEM and thus modifications done by the supplier are then available to the OEM and so risks of model discrepancies are reduced since the corrections are done at a single site.

Level 3: Level 3a: Use of OEM Models in Cooperation

The OEM owns a model and delivers it to the supplier who is then charged to industrialize the model and generate production code generation out of the model. Different to cooperation Level 2, the supplier can introduce functional modifications in the OEM model. The kind of Know-How added by the supplier can be for example specific calculations mechanisms such as special filters (e.g. replacement of PT1 filter by a Butterworth filter to achieve certain goals). The modified models are delivered back to the OEM for further development. In general, for all cooperation levels, a CIL (Customer Interface Layer) is needed to combine OEM functions with Bosch functions.

Level 3b: Use of Bosch Models in Cooperation

The supplier provides its own models to the OEM who can then enhance the model by its own functionalities and Know-How. The OEM delivers back the modified model to the supplier who is then in charge of industrialisation and production code generation. The final responsibility for the model (physical Behaviour as well as code out of the model) remains with the supplier who should review the OEM functional modification for approval. The development time of OEM specific functions can be drastically reduced with this cooperation level since there is no need for the OEM to deliver any specification or schematic that would have to be analysed by the supplier and then interpreted in the model.

Although Know-How/functionality is appended to the original model with this cooperation level, the ownership of the model remain with the original provider of the model; i.e. Ownership of model remain with OEM in case of cooperation level 3A and ownership of model remain with Bosch with cooperation level 3B.

Level 4: Joint development

The joint development deals with a common ownership of the models. The base model can be created at the start of the partnership or can be provided by one of the party. The level of contribution from the supplier and the OEM is comparable and the created Intellectual Properties are shared. It leads to accelerated development: a unique model can be continuously exchanged between the supplier and the OEM or modified by one party with the contribution of the other party. As a constraint, it is necessary to define clear responsibilities between the supplier and the OEM.

Standards with Model-Sharing cooperation

ASAM-MDX standard and AUTOSAR standards are being considered in this paper. The ASAM-MDX standard is an ASAM (Association for Standardisation of Automation and Measuring systems: http://www.asam.net) standard, and the signification of MDX is "Meta Data Exchange Format". This format is often used with another ASAM standard called CDF (Calibration Data Format). AUTOSAR stands for "AUTomotive Open System ARchitecture": http://www.autosar.org. This standard has been released by a consortium of car makers, software suppliers and tools suppliers. This standard describes also data specification for development collaboration.

Both standards (ASAM-MDX as well as AUTOSAR) describe the interfaces and data definition used in the corresponding models within XML files. The AUTOSAR standard is more complete since it describes also the Basic Software as well as the interfaces between the Application Software and the Basic Software. Both standards can not be applied at the same time on a model: the code can be either generated with a MDX target or with an AUTOSAR target. The most evident advantage of such standard remains in the fact that the data descriptions can be easily shared between OEM and suppliers at the same time as the models exchange. Since the format used is XML-language, these files can be processed more easily than Excel-like formats and are less sensitive to characters issues. Another advantage of these standards is that it helps to avoid developing specific tools or scripts as it is the case when using specific OEM or supplier formats. Development activities can then be performed with standard tools from the market without any deep customization.

As generally known, a function design can be performed by using different modelling styles. Hence standards may have an impact on the modelling pattern. The cooperation between OEM and suppliers with models exchanges can be eased if both partners are using the same standard for their Model Based Development tool chain. Non-use of same standard can really impede model exchange, especially with regard to library blocks intended for simulation as well as for code generation; some library blocks may include memory states like for filters or flip-flop, and thus the memory states can be described with workspace elements in form of Simulink® objects or MATLAB objects.

With R2012B onwards, MathWorks has introduced with a PSP (= Pilot Support Package) in Simulink® a set of MDX objects (derived from Simulink® objects) which have been developed in cooperation with Bosch, intended for use in cooperation projects between Bosch and its customers. Together with this PSP, Bosch has developed a Simulink® library containing AUTOSAR services and other specific functions (e.g. BSW specific functions). In case of Simulink® model exchange containing these library blocks, a simulation can be performed since these objects are based on Simulink® objects; code generation will however require the use of the MDX package. If however the data specification on customer site are based on MATLAB objects, simulation will be performed with default values but not with the specified version; a conversion will therefore be needed to have appropriate simulation. Furthermore, working with a standard for the data description avoids also to create its own specific data description rules. It then avoids to create its own scripts to generated the data description files during the code generation phase.

From a modelling point of view, a standard like AUTOSAR provides also standardized interfaces with the Basic Software like diagnostic interfaces, and thus permits to connect easier Application Software functions to the Basic Software services.

From an integration point of view, if the OEM provides Software Sharing code which has been generated with standardized interface, the integration of the Software Components in the supplier Software is made easier since the files can be processed with the standard supplier tool chain, thus avoiding usage of specific tools to generate adapter layers with specific interfaces mechanisms. One of the main objective of AUTOSAR as standard is to ensure portability of functions towards different platforms and thus ease integration of Software Components from different development partners. Therefore data descriptions are defined in an XML file, which can be processed by a tool during the software build phase to generate automatically the appropriate header and source code files for data declaration and definition.

When sharing code with a supplier, the alignment of standard used at OEM side with standard used by the integrating supplier allows an enhanced efficiency in the continuous integration process; thus necessary software adaptations can be automatized more easily.

Data consistency is a crucial element in the automotive embedded software development (especially when using pre-emptive and cooperative tasks in a single-or multicore context). Data specification information within standard files (MDX and AUTOSAR files) can be used to ensure the data consistency and thus these files can be directly be processed during the software build phase to take care on data consistency mechanism in the final software (hex-file). For MDX file, the so called tool MCOP (Message Copy OPtimizer) is used whereas for AUTOSAR files, the RTE generator ensures the data consistency mechanisms especially for Sender-Receiver implicit communication. The configuration of MDX objects for a Simulink® model is performed using the MDX explorer (derived from standard Simulink® model explorer) and is part of the data dictionary to be shared between development partners and the configuration of AUTOSAR objects is performed in the workspace (to create AUTOSAR objects) as well as with the AUTOSAR Mapping Editor for Simulink® to prepare the model for RTE configuration. Working with the same standard between OEM and supplier can reduce the effort of the model preparation at the supplier side for the code generation in case of Model Sharing Level 2 (or so-called Commissioned Development).

With the Model Sharing level 0, the MDX or AUTOSAR standards are supported by tools used at Bosch to generate the artefacts for Virtual Prototyping, done with INTECRIO or EVE [1] [2]. Some tests have been done with Software Sharing code which are not using MDX or AUTOSAR. A non-negligible effort had been spent to adapt the tool and scripts to the code and some information were missing and the way to extract is not as reliable as with an MDX or ARXML file.

The ASAM-MDX standard

The ASAM-MDX standard is supported by the tool chains at Bosch DGS-EC for years and the MDX target is part of the Simulink® tool chain. The name of the MDX files is in form of *_mdx.xml. The structure of the MDX files is organized into several parts:

-Data dictionary for the variables: it describes the implementation information such as the Datatype, the Compu Method, the Data Constraints, the Memory Location, the type of communication -Data dictionary for the parameters: it describes the implementation information of each variable and parameters such as the Datatype, the Compu Method, the Data Constraints, the Memory Location, the Record Layout -Description of the Compu Method -Description of the Data Constraints -The services: for each runnable, it describes the direction for each interface (READ, WRITE or READWRITE) and the type of access. The information provided in this part is very important for the tools which ensure the data consistency -A list of internal variables, interfaces, parameters and runnable defined in the Software Component -A list of interfaces and parameters which are exported by the Software Component -A list of interfaces and parameters which are imported by the Software Component The definition of the Compu Methods and the Data constraints can be done in self-containment or centrally defined. In addition to the MDX files, a CDF file can be used to define the default values for the parameters.

The MDX and CDF files are generated by Simulink® with the AddOn MDX Exporter from MathWorks. It is necessary to create MDX elements in the Workspace such as MDX.Variable and MDX.CalPrm. Some information, which are not present in these Workspace elements like memory location or scope (import, local, export), are defined in the MDX Explorer. It is accessible from the Simulink® model and its content is embedded in the model. A primary role of the MDX files is to generate automatically the headers files for the data declaration during the software build phase. The headers are enriched with other information. It avoids to generate them during the code generation phase. Hence it permits to have a flexible configuration depending on each project. Another primary role is to be able to generate automatically an A2l file. The A2l is a standard file from ASAM association which contains the complete data description for the calibration tools like INCA. Without XML files like MDX file, it would be impossible to generate the A2l file with the c code and header file only since they do not contains the Compu Method description for example.

Describing all the data and the scope of each interface in an XML file for every Software Components offers many other advantages, especially with self-containment. During the software build phase, it is indeed possible to do a check if there are open interfaces. The software build can be interrupted in an earlier phase than without this functionality and a log file that provides a list of the issues is generated. It is also possible the check the data definition incoherencies for the interfaces: for example a data type difference between an imported interface and the exported interface.

With the new generation of microcontrollers with Multi-Core technology, the MDX standard provides further advantages for the integrating suppliers regarding the data consistency constraints. With Multi-Core microcontroller, the runnable in the Application Software part can be distributed over several cores. The MDX standard introduces the concept of import and export messages. The data consistency between inputs and outputs communicating between two different cores has to be ensured. In the Bosch DGS-EC software build tool chain, this is done with the tool MCOP. It is a tool included in the DGS-EC software build tool chain and it uses the READ/WRITE access defined in the MDX files as input to determine which data has to be protected by doing a data consistency analysis. By using MCOP solution with MDX files, there is no need to implement data consistency features in the c code, since the consistency is implemented during the software build process. The consistency implementation is adapted to every software configuration (task distribution and functions scheduling). It is a mechanism similar to the implicit communication with the AUTOSAR sender-receiver interfaces. The main difference remains in the fact that the implementation of the data protection with MCOP and MDX files is done in the object code and the ELF file with the VARED mechanism during the compilation phase. With AUTOSAR, the data protection is implemented during the RTE generation, in an earlier phase of the software build process.

Figure 3 -Bosch MCOP concept

In a Model Sharing context, the support of the MDX standard is depending on the modelling tools and their configurations. With ASCET tool, the Bosch DGS-EC target includes a feature which permits the code generator to generate an XML file called PaVast which has a format and a semantic very similar to the MDX format. Both format are supported by the same tool chain during the software build process. If an OEM wants to exchange ASCET models with Bosch more easily, it is recommended to use a compatible target to avoid the use of a conversion tool. With the Simulink® tool, the MDX files can be generated with the MDX Exporter from MathWorks. It can be either configured in the OEM Simulink® environment or it is included in the Bosch DGS-EC Add-On which offers a complete code generation environment compatible with the Bosch DGS-EC code development rules. This Add-On can be delivered to any OEM in the framework of a cooperation contract. The cooperation between OEM and supplier when exchanging models can be eased when both development partners are using the same MDX standard for their Model Based Development tool chain. It can be a blocker when exchanging library blocks for the code generation. Some library blocks, like filters or flip-flop, may include memory states. For example, the memory states can be described with the Workspace elements MDX.Variable. If the user of a Simulink® model who need this library does not have the MathWorks MDX Exporter, he shall do with a script a conversion of MDX Workspace elements into Simulink® elements in order to be able to run a simulation. With a Model Sharing Level 1 or 2, if he OEM delivers Simulink® models without any MDX support, the MDX configuration can be added by the supplier. The adaptation is done in two steps. The first step is dealing with a conversion of the OEM data dictionary into MDX elements in the Workspace. The conversion task can be eased if the OEM is able to provide a data dictionary in MDX format. It can be more easily converted into MDX elements since the XML format can be processed more easily than Excel format and is less sensitive to issues with bad fields' content with bad characters.

The second step is dealing with information which are not present in these Workspace elements like memory location or scope (import, local, export). They shall be defined in the MDX Explorer which is accessible from the Simulink® model and these data are embedded in the model. The filling of the MDX Explorer can be done more easily if the OEM is able to provide a data dictionary in MDX format containing the useful information like the scope (import, local, export). The information can also be completed with MATLAB scripts through specific API.

Figure 4 -Simulink MDX Exporter

With the use of XML files for the support of a standard like MDX, it is strongly recommended to use an automatic code generator. The MDX files contain in general hundreds of lines of code with tags.

The AUTOSAR standard

Bosch DGS-EC is working on an efficient use of the AUTOSAR standard in a scope of development for series. It is a more complete standard than the MDX standard since the Basic Software is standardized and clearly decoupled from the Application Software. It describes the concept of Virtual Functional Bus which is supported by the Run Time Environment (or RTE). In the same way as the MDX standard, the data are described in a XML file, it is called ARXML (AUTOSAR XML). It offers a much more complete semantic and is based on AR Packages and AUTOSAR element references. Contrary to the MDX standard, the infrastructure interfaces such as diagnostic, NVM, DCM interface are supported as standardized Basic Software interfaces. It is a main advantage in comparison with MDX since the BSW interfaces can be implemented in the models and described in the ARXML files. With Software Sharing context, it avoids using implementing Sender-Receiver interfaces in the Software Components and developing Customer Interface Layers to adapt these Sender-Receiver interfaces to the integrating supplier BSW specific interfaces. Another advantage of the AUTOSAR standard is dealing with standardized AUTOSAR service libraries. These service libraries have standardized names and argument names. Their algorithms are also precisely described so that they can be implemented by any integrating supplier. AUTOSAR service routines do not use AUTOSAR mechanisms: they can be used for developments with MDX standard as well as AUTOSAR. With the Simulink® tool chain, Bosch DGS-EC is able to deliver Simulink® library blocks supporting the AUTOSAR service libraries, since they are not all available with the native MathWorks blocks.

AUTOSAR is supported by many tools from the market, this is an important advantage since the inhouse development of specific software development tools can be avoided. For an OEM working with AUTOSAR, there is no need for its integrating suppliers to develop specific tool. It would be very costly if every OEM and supplier had their own standard. AUTOSAR has changed the landscape of the manufacturer -supplier relationship. With this standard, it can be easier than ever to integrate the code of an OEM or a Third Party into an integrating supplier software. It is a mean to ease the Software Sharing and open new cooperation frameworks. The structure of the ARXML file is however not fixed as for MDX: the structure ordering is depending on the AR-Package structure and AR-Packages name. The AR-Packages can be spread over several ARXML files and a Software Component can be described by several ARXML files, for example one ARXML file for each AR-Package. The elements properties are not defined only by short name, but by reference to the AR-Packages.

The main automotive modeling tools ASCET, TargetLink® or Simulink® are supporting AUTOSAR. With ASCET, the concept of AUTOSAR Model has been introduced in the tool. It is very similar to the non-AUTOSAR models, especially regarding the modelling of the functionalities. From an architecture point of view, an atomic Software Component is represented by one ASCET module. A composition can be represented in the ASCET Project by an assembly of ASCET modules.

Figure 5 -Composition in ASCET

Instead of Import / export message there is a specific block available for the Sender/Receiver interfaces and the type of communication (explicit VS implicit) can be selected. The second difference is dealing with the AUTOSAR Mapping Editor which contains two sheets: the ports, the interfaces (Sender/Receiver, Client/Server), the IRV and the runnables are defined in the first sheet. Their mappings to the models inports, outports and the function call is ensured in the second sheet. The content of the AUTOSAR Mapping Editor can be filled automatically with a script thanks to APIs. The script shall be configured to fit to the naming convention applied in the environment development. For example, a Receive Port could have a prefix "R_" or "RP_". This automation is possible if the ports, interfaces and data elements share the same name root. This is a rule established at Bosch DGS-EC and it allows to do also an automation of the AUTOSAR composition, called "autocomposition".

Figure 8 -Simulink AUTOSAR Mapping Editor

The third difference is dealing with the accesses to the infrastructure: there are described with Client-Server interfaces and many of them have standardized names. "Simulink® Function" and "Simulink® Caller" blocks can be used.

Figure 9 -AUTOSAR FiM interface modelling in Simulink

The software build process has to be adapted to an AUTOSAR project: in comparison with non-AUTOSAR project, a tool called RTE Generator shall be invoked. It generates c and h files from the ARXML abstraction layer. It generate the RTE which ensure the communication. In most of the projects; there is a mix-mode with a part of the software in MDX or any other specific OEM standard. The implementation of Customer Interface Layers is required and is a drawback to a smooth transition to AUTOSAR in comparison to a "big bang" introduction. It requires then additional development effort and additional RAM consumption. There is also an impact on the OS scheduler: a pure AUTOSAR scheduler can not be implemented. The legacy OS scheduler references RTE task container tasks which are described in a configuration ARXML.

Figure 10 -Bosch Software build Process

The implicit Sender-Receiver communication is recommended to ensure the data consistency for the communication between two different cores in a Multi-Core microcontroller or between two different tasks with a pre-emptive Operating System (OS). Buffers are created during the RTE generation in the c and h files. This is done indeed before the compilation phase and it does not require specific tools as for MDX standard, since the protection mechanisms are described in the standard and supported by the RTE Generators.

In a Model Sharing context, the tools ASCET, TargetLink® or Simulink® offer the possibility to develop AUTOSAR Software Components without spending so much time on the target configuration. With ASCET tool, an AUTOSAR target configuration is available and the AUTOSAR model can be quite easily exchanged between OEM and suppliers. It is however very important to keep in mind that some AUTOSAR features availability is depending on the AUTOSAR release. All the partners in a cooperation framework shall agree on the supported release before starting the development to avoid model incompatibilities. In the same way, it is very important for an OEM or a third party to agree on the AUTOSAR Release supported by the RTE Generator. They have to be sure that the required AUTOSAR features in the models are supported by the RTE Generation version in use for the project. With the Simulink® tool, the same precautions have to be taken regarding the AUTOSAR release compatibilities. As an example, the PRPortPrototype feature has been introduced AUTOSAR 4.1.1. If the development partners are working with different Simulink® versions, this feature may not be available in an older version and there would be an issue in the AUTOSAR Mapping Editor Content. With the same example, this feature could be generated in the ARXML but it is not sure whether the RTE Generator version in use at the integrating supplier side would support this feature. Developing an AUTOSAR Software Component has an impact on the modelling patterns. For example, multi-triggering on runnable level is not possible, since one runnable shall be mapped with only one event. The standardization of the BSW interfaces is a great enabler for Model Sharing. An obvious example are the DEM / FIM diagnostic interfaces. In comparison with MDX, every development partners can use the same service access and there is no need to develop customer specific services on the integrating supplier side. As a drawback it reduce the possibilities to bring innovations in these services and the OEM and suppliers have less levers to differentiate their technology from their competitors. Shared software development for electronic control units becoming more and more important. In order to cope with the complexity of the Software development for Engine Control, a strong and highly flexible Software architecture is required. The answer of Bosch to this challenge is the creation of the Software architecture VeMotionSAR TM that strengthens the cooperation with the OEMs and that has been published in Internet (http://www.bosch-vemotionsar.com). One of the main benefits of this architecture is the modularity of the function description and the definition of the interfaces. It permits to describe individually the various specifications of the corresponding development partners' functionalities in a highly modular architecture domain according to their resources / tools.

Migration from legacy standard to MDX

The ASAM-MDX standard is mature and is in use at Bosch DGS-EC for years for series project. With the new Multi-Core microcontrollers and the need of data consistency mechanisms, it can be a good alternative for the integrating suppliers who are using specific standards which are not supporting Multi-Core. It is therefore interesting to analyze the impacts and the constraints on Model Sharing cooperation's when doing a migration to the MDX standard. AUTOSAR is a promising standard in the automotive embedded software and more and more control units have an AUTOSAR RTE with a partial or complete AUTOSAR Application Software. The description of migrations uses cases are focused on Simulink® tool in this chapter.

For the conversion of Simulink® models into MDX, the main challenges are oriented to the migration of the Workspace elements and the configuration of the MDX Explorer. The Workspace elements can be easily converted into MDX elements with MATLAB scripts. Some information contained in the Workspace elements could be lost if the original models are using Custom Storage Class. Depending on the features, they can either be taken into account in the MDX Explorer or may lead to some changes in the model. For example, the attribute to know if a variable shall be stored in the Non Volatile Memory can be set in a Custom Storage Class. During the migration, this attribute shall be taken into account in the MDX Explorer by setting the memory location to a Non Volatile Memory location. This example demonstrates that the MDX Explorer content shall be updated at the same time as the Workspace elements. Since all the MDX Explorer attributes can be accessed with APIs, a MATLAB .m file for the MDX Explorer configuration can be created during the migration. Running this file will fill the MDX Explorer content. This is the solution chosen at Bosch for converter scripts. The migration to the MDX standard may have also an impact on the modeling pattern in a Simulink® model. A frequent issue is faced for inport blocks which may uses the value of the outports in the same runnable. The inport and the outport can not have the same name, the inport shall be removed and the signal shall be replaced by a Unit Delay block connected to the outport. It is more complicated to handle it if the same outport is also initialized in a separate initialization runnable. For this case, a specific UnitDelay block, which includes a memory state value defined in the Workspace as a MDX.Variable, has been created at Bosch DGS-EC. Another impact on the modelling patterns is dealing with the Multi-Core constraints: it is not possible to keep the multi-triggering on runnable level. The functionality need to be refactored or the runnable content needs to be duplicated. The duplication may be complicated in case of state machine or any functions containing state values.

Migration from legacy standard or MDX to AUTOSAR

For the conversion of Simulink® models from legacy or MDX to AUTOSAR, the main challenges are oriented to the migration of the Workspace elements and the configuration of the AUTOSAR Mapping Editor. The most important challenge for developments with AUTOSAR is to be as efficient as the standard it is supposed to replace. For ECU Software development with its complexity, it is reasonable to consider that it would not lead to short-term cost reductions. However, it could avoid spending more efforts in long-term by reducing the development and maintenance effort of specific tools in case an OEM or a supplier is using its own standard. A migration to AUTOSAR makes sense if the tool chain is ready for efficient development with AUTOSAR from an economic point of view.

The experience shows that it is necessary to write scripts to reduce the manual effort and the risk of errors. The advantage of Model Based Development lies in the fact that the AUTOSAR adaptation can be done directly in the model used for the code generation. Prior to the migration task, many clarifications with the OEM are necessary such as:

-Architecture: one model = one atomic SW-C, or one model = one Runnable ? -AR-Package structure -Naming conventions for the AR elements short names -Restriction on the naming rules for the ports, interface and data elements to allow an "autocomposition" The Workspace elements can be converted into AUTOSAR elements with MATLAB scripts. At Bosch DGS-EC, the measurement points are defined as Per Instance Memory (PIM) or Inter Runnable Variables (IRV) whereas they are Simulink.Signal or MDX.Variable with other targets where the inputs and outputs are also Simulink.Signal or MDX.Variable. The script shall detect the inputs and the outputs in the models in order to identify which Simulink.Signal or MDX.Variable shall be converted into AUTOSAR.Signal and the other into PIM or IRV. The AUTOSAR Mapping Editor can be filled automatically with a script. There are also impacts on the modelling patterns:

-The multi-triggering on runnable level is not compatible with AUTOSAR: with a Simulink® model, it is not possible to have a multi-triggering on the Function Call subsystems representing the runnable since one runnable shall be mapped to one event. -The messages exchanged between runnable shall be converted as Inter Runnable Variables (IRV).

-With Simulink, the measurement points are defined in MDX as global variable with a resolve signal to Workspace: in AUTOSAR they shall be defined as static memory or Per Instance Memory (PIM) or IRV. -At Bosch DGS-EC, many legacy services can not be mapped to AUTOSAR standardized clientserver interfaces. In case of Software Sharing, those interfaces shall be replaced by Sender-Receiver interfaces and the integrating supplier shall map them to their equivalent services via an adapter. -the physical system constants are not supported by AUTOSAR, a work-around is necessary In order to prepare a seamless migration to AUTOSAR for mid or long term, some measures can be taken in the modelling pattern rules for the legacy models to ensure a compatibility with AUTOSAR. The modeling pattern shall be defined so that a model could be automatically converted into AUTOSAR without any rework.

-For the interpolation routines, it is necessary to use blocks which support MDX and AUTOSAR at the same time. The Simulink® look-up table will support soon both MDX and AUTOSAR standard with AUTOSAR R4.x libraries Ifx and Ifl. -For the Dem and FiM interfaces in AUTOSAR, if similar services are available in legacy environment, it could be possible to create Simulink® blocks with an embedded automatic configuration, depending on the choice between the legacy or AUTOSAR target. -Legacy services which are not identical with the AUTOSAR similar service require to define modeling pattern adaptations.

Summary

Model Sharing is currently applied at Bosch for several series projects and is leading to clear improvements in development efficiency. Use of Standards (e.g. ASAM (MDX, CDF …) AUTOSAR (service libraries, methodology …) as well as standardized interfaces specifications (e.g. as published with AUTOSAR R4.x) can significantly ease exchange of models.

The ASAM-MDX standard is supported by the code generation tool chains for years at Bosch and permits to perform interfaces coherency check during the Software Build process as well as to provide information to build the A2l file. With the Multi-Core microcontrollers, the MDX files are used by the tool MCOP to ensure the data consistency.

The AUTOSAR standard clearly defined a separation between the Basic Software and the Application Software and provides standardized interfaces with standardized mechanisms. In comparison with MDX, the infrastructure interfaces with the Basic Software are standardized which is a lever to improve the model exchanges. For engine control unit software, the Process, Method and Tool for AUTOSAR developments are not yet as efficient as with MDX developments. Bosch is working actively with tool editors to reduce the gaps. On one side, Tier 1 need to know if the OEM want to base their future developments with the AUTOSAR standard. On the other side, OEM want to know when the Tier 1 will be able to support AUTOSAR in an efficient way. The approach at Bosch consist in editing internal AUTOSAR coding guidelines. The current tasks are focused on the identification and the reduction of gaps between those guidelines and what is supported by the tools.

It is possible to migrate a legacy Simulink model to MDX or AUTOSAR. Many migration tasks can be automatized with scripts. The modelling patterns are also impacted and if the migration to AUTOSAR is a long-term strategy, it is recommended to take into account this modelling constraints in the legacy models in short term.

Bibliography

Figure 6 -

 6 Figure 6 -AUTOSAR ports modelling in ASCET An additional tab has been introduced to configure the runnable to events mapping. The naming convention for the AR-Package and many AUTOSAR elements are configured in an XML configuration file.

Figure 7 -

 7 Figure 7 -ASCET runnable to event mapping For the development of AUTOSAR Software Components, a cooperation between MathWorks and Bosch has been established within the framework of a strategic partnership in order to support AUTOSAR with Simulink® in an efficient way. At first glance, a Simulink® model for AUTOSAR looks like a model for MDX. There are three main differences. The first one affects the Workspace elements: it is necessary to create AUTOSAR elements such as AUTOSAR.Signal and AUTOSAR.Parameter. ARXML files can be imported through an API to load for example the Internal Behavior or central elements for the central definition of AUTOSAR elements such as base types or Compu Method.

  : 1. Dr. M. Tanimou, Dr. M. Münzenmay, K. Zimmermann, Robert Bosch GmbH; Dr. B. Lumpp, Dr. E. Trapel, E. Bouillon, Dr. M. McMackin, MAN Truck & Bus AG: Software-in-the-Loop durch Co-Simulation von EDC-Modell und GT-Modell; Mainz, 14 th MTZ-Conference 2014-01-0189 -virtual powertrain creation, 2013 2. Lumpp, B., Tanimou, M., McMackin, M., Bouillon, E. et al., "Desktop Simulation and Calibration of Diesel Engine ECU Software using Software-in-the-Loop Methodology," SAE Technical Paper 2014-01-0189, 2014, doi:10.4271/2014-01-0189 3. S. Louvet, Robert Bosch (France) SAS, Dr. U. Niebling, Dr. M. Tanimou, Robert Bosch GmbH : Model Sharing to leverage customer cooperation in the ECU software development; Toulouse, ERTS 2014-Conference, 2014


Member, IEEE, Ladislau Matekovits Senior Member, IEEE Valeria Loscrí
email: vale-ria.loscri@inria.fr

Ildiko Peter
email: ildiko.peter@polito.it

Member, IEEE Anna Maria Vegni
email: annamaria.vegni@uniroma3.it

Ladislau Matekovits
email: ladislau.matekovits@polito.it

In-body Network Biomedical Applications: from Modeling to Experimentation

Keywords: Nanomedicine, TiO2 particles, THz band channel capacity

Innovative diagnostic approaches and therapies are more and more based on the use of injections or oral delivery of nanoparticle sized substances. For a better understanding of the overall phenomena, aiming to facilitate a safe application at large scale, the development of accurate models and analysis techniques are required. These techniques take into consideration different aspects of the overall process: accurate numerical modeling of the different phases of the nanoparticles in the body, and knowledge of the local environment, that can be varying very fast within a short-range in the body itself. Such aspects should be taken into account to correctly predict the amount of drug and its timely release for the specific disease. Deep and accurate analysis of the interaction between the nanoparticles and the biological fluid where the nanoparticles are immersed is mandatory for an efficient correlation of all these aspects.

Because of their biocompatibility, in this paper, we focus our attention on systems of Titanium (Ti), and its oxide (e.g., TiO2), given their specific features in terms of density, lack of cytotoxic effects, etc. Specifically, we present the study and design of an in-body system by characterizing each of the emission, diffusion, and reception processes with a proper realistic model. The theoretical investigation is further supported by experimental study of the morphology and other important characteristics (e.g., the pH of the particles, and thermal stability) of TiO2 systems when immersed in a Ringer solution, in order to derive important information related to their potential toxicity inside the human body.

I. INTRODUCTION

Nanotechnology is a challenging new research area that finds applications in several areas of modern life i.e., from biomedical to military, and from environmental to the industrial fields. For instance, in nanomedicine, the use of nanodevices (i.e. nanorobots and nanosensors, opportunely functionalized with medicament) are intended to both diagnostic and therapeutic purposes [START_REF] Svenson | Multifunctional Nanoparticles for Drug Delivery Applications: Imaging, Targeting, and Delivery[END_REF]- [START_REF] Loscrí | An acoustic communication technique of nanorobot swarms for nanomedicine applications[END_REF] by enhancing their effectiveness, as well as increasing their tolerability in the body by interfering at a minimum level with the immune system [START_REF]On the affection of the human immune system on a nanoparticulate nanomedicine system[END_REF]. Novel nanomedicine applications arise to the term "theragnostics", which is intended as a treatment strategy combining therapeutics with diagnostics. Basically, theragnostics includes a wide range of areas, including personalized medicine, and pharmacogenomics, in order to develop efficient new targeted therapies.

Different types of nanoparticles can be exploited for nanomedicine applications, such as gold and silver nanoparticles, titanium dioxide TiO 2 nanoparticles, dendrimers, Carbon Nano-Tubes (CNTs), etc. [START_REF] Kumar | Handbook of Particulate Drug Delivery[END_REF]. The use of nanoparticles for biomedical and sensing applications is mainly as carriers for localized Drug Delivery Systems (DDSs) [START_REF] Hossen | Vascular-targeted nanotherapy for obesity: Unexpected passive targeting mechanism to obese fat for the enhancement of active drug delivery[END_REF]- [START_REF] Femminella | A molecular communications model for drug delivery[END_REF]. The aim is to provide a controlled drug concentration in a given location, where the medication is needed [START_REF] Svenson | Multifunctional Nanoparticles for Drug Delivery Applications: Imaging, Targeting, and Delivery[END_REF]. Alternatively, in the case of diagnosis, the aim is to provide information about in-body conditions, by opportunistically measuring specific parameters and/or chemical concentrations, etc. [START_REF] Freitas | What is nanomedicine?[END_REF] altering as less as possible the local environment. Particularly, colloidal silver has been used as an antibacterial agent by weakening DNA replication and inactivating proteins, while the low toxicity in biological systems of gold does not allow its efficient use for antibiotic therapy [START_REF] Zhou | Antibacterial activities of gold and silver nanoparticles against escherichia coli and bacillus calmette-guerin[END_REF]. In [START_REF] Bhumkar | Chitosan reduced gold nanoparticles as novel carriers for transmucosal delivery of insulin[END_REF], the authors use gold nanoparticles for diagnostic and drug delivery applications by exploiting chitosan, with the dual purpose of (i) acting as a reducing agent in the synthesis of gold nanoparticles, and also (ii) promoting the penetration and uptaking the peptide hormone insulin across the mucosa.

The use of TiO 2 , SiO 2 and TiO 2 /SiO 2 obtained by different analytical techniques, and in different arrangements, is presented in [START_REF] Song | Amphiphilic TiO2 Nanotube Arrays: An Actively Controllable Drug Delivery System[END_REF]- [START_REF] Signoretto | Effect of textural properties on the drug delivery behaviour of nanoporous TiO2 matrices[END_REF] for controlled delivery of drugs for therapeutic purpose. The authors highlight also the positive effect of such particles, since they act against bacterial infection too and facilitate the osteoblast cell adhesion and growth. Additionally, particles with high surface area, large pore volume and proper pore size are important to guarantee an excellent adsorption capacity in the therapeutic system.

In the context of body area networks [START_REF] Chen | Body area networks: A survey[END_REF], nanoparticulate DDSs are therapeutic methods that use nanoparticles to achieve diagnostic effects at the exact time, drug concentration level, and location in the body, while minimizing the effects on other healthy locations. In both DDS and diagnostic applications, common methods adopted include inhalation, intravenous and intramuscular injection, as well as ingestion [START_REF] Cleland | Emerging protein delivery methods[END_REF]. In all these methods, the most important thing is to characterize the interaction between the in-body solution and the specific nanoparticles.

The Molecular Communication (MC) [START_REF] Nakano | Molecular communication among biological nanomachines: A layered architecture and research issues[END_REF]- [START_REF] Felicetti | Tcp-like molecular communications[END_REF] paradigm allows the analysis of a nanoparticulate DDS from the information theory perspective, as a tool to study nanoscale biological and medical systems [START_REF] Chahibi | Antibody-based molecular communication for targeted drug delivery systems[END_REF], [START_REF] Chahibi | Pharmacokinetic modeling and biodistribution estimation through the molecular communication paradigm[END_REF]. In [START_REF] Chahibi | Pharmacokinetic modeling and biodistribution estimation through the molecular communication paradigm[END_REF] the pharmacokinetics of a DDS is analytically modeled through the abstraction of MC paradigm. The authors consider physicochemical processes in the particle propagation, such as (i) the advection process i.e., the transport of particles due to the blood velocity, (ii) the diffusion process i.e., the Brownian motion of particles, (iii) the absorption process i.e., the particle absorption through tissues surrounding the blood vessels, (iv) the reaction process i.e., the reaction between the particles and the blood, and (v) the adhesion process i.e., when biomolecules bind to the drug-loaded particles. Finally, in [START_REF] Chahibi | Molecular communication noise and capacity analysis for particulate drug delivery systems[END_REF], Chahibi and Akyildiz model a drug delivery system affected by noise effects in the nanoparticulate scenario of the cardiovascular system.

In this paper, we refer to the MC paradigm in order to analyze main features of a DDS, where nanoparticles are emitted, diffuse and then are captured (received) in a biological fluid. The DDS can be modeled as an end-toend system, where the nanoparticle emission process can be assumed as a transmitted message, and the received message is the nanoparticle reception process. Furthermore, in order to provide completeness to the paper, we carry out experimental results on TiO 2 nanoparticles flow, which has been immersed into a biological fluid. As it can be noticed, in this paper a multi-disciplinary approach has been followed for the DDS modeling. Specifically, we refer to our previous work [START_REF] Loscrí | Modeling and experimental analysis of an in-body area nanonetwork[END_REF], where a nanoparticulate system has been modeled through pharmacokinetics laws, and provide a more accurate end-to-end DDS model, together with extensive experimental results.

The contribution of this paper is twofold. First, we model a drug delivery system for nanomedicine applications, through the characterization of nanoparticles emission, diffusion, and reception processes, that are analyzed from the information theory perspective. We assume that a nanoparticle flow is introduced within a biological fluid, and it is free to diffuse until reaching a given position. The model linking the nanoparticle emission and reception is investigated as an end-to-end system, where the capacity is derived analytically in case of ideal, and non-ideal scenarios. Finally, we carry out an experimental analysis of specific nanoparticles (i.e., TiO 2 nanoparticles) in a biologic-like fluidic medium, in order to infer main features as pH stability and diffraction patterns modification determined by mediumterm permanence in biological-like fluid or quantification of the activation energy in the given conditions. Some preliminary results of our investigations have been recently presented in [START_REF] Loscrí | Modeling and experimental analysis of an in-body area nanonetwork[END_REF] that have been further enriched here. In particular, (i) the development of the reception process and (ii) additional experimental characterizations on the behavior of the considered TiO 2 system in a biologic-like fluidic medium have been considered.

Notice that the choice of TiO 2 particles is due to their benefits for biomedical applications. Indeed, among other existing systems, because of their low density, excellent corrosion resistance, lack of cytotoxic effects, and good mechanical properties, Ti and its compounds (i.e., TiO 2 ) are well established materials for biomedical applications, as orthopedic and dental implants, cardiovascular stents, joint replacement [START_REF] Long | Titanium alloys in total joint replacementa materials science perspective[END_REF]- [START_REF] Peter | Investigation on cobalt based alloy modified by titanium for dental application[END_REF]. The use of a controlled drug delivery of TiO 2 particles could enlarge the potential applications in biomedical fields.

This paper is organized as follows. In Section II we present our general (and not specific to materials discussed later in the paper) nanoparticulate drug delivery model. We highlight the main processes that occur when a concentration of nanoparticles is introduced in what we name here "compartment" to indicate a closed volume containing a biological fluid. Specifically, we detail the laws characterizing the nanoparticle emission/ transmission1 , diffusion, and reception processes, from the information theory perspective. At the end of this section we will be able to derive the capacity of the proposed system (both in case of ideal and non-ideal nanoparticle reception). In Section III we describe the details of the experiment we dealt in order to infer the main characteristics of the interactions between the particles and the biological fluid. Finally, conclusions are drawn at the end of the paper.

II. CHARACTERIZATION OF THE IN-BODY PHASES

As early described in [START_REF] Loscrí | Modeling and experimental analysis of an in-body area nanonetwork[END_REF], our proposed nanoparticulate model is based on pharmacokinetics laws, which provide a mathematical basis for analyzing how the human body reacts to the administration of "external substances" (i.e. a fluid with a given nanoparticle concentration). Pharmacokinetics considers the rate at which drug concentrations change in the body, and includes the kinetics of absorption, distribution, metabolism and excretion of a drug. Also, from [START_REF] Chahibi | Pharmacokinetic modeling and biodistribution estimation through the molecular communication paradigm[END_REF], in a blood network, we can suppose that a nanoparticle flow propagates subject to the physicochemical processes such as absorption, reaction, adhesion, diffusion, and advection.

In this paper, we rely on one compartment pharmacokinetics model for oral drug administration. This is an empirical approach, where the compartment can represent a body/organ volume, and a compartment is modeled with a biological fluid (e.g. the Ringer solution as described in Section III) into which a flow of nanoparticles is added by a rapid single dose (emission process), diffuses in the body (diffusion process), and finally reaches a given location for therapeutic/diagnostic aim (reception process).

A. Nanoparticle emission process

When a flow of nanoparticles is injected in the biologic fluid, the nanoparticle concentration i.e., C N P (t), increases according to an uniform behavior in the "compartment", until reaching a maximum value. The analysis of this model relies on a simple mass balance compliant with the dissolution kinetics of TiO 2 nanoparticles [START_REF] Utembe | Dissolution kinetics of titanium dioxide nanoparticles: the observation of an unusual kinetic size effect[END_REF] that have been used in the experiments described in Section III.

The mass balance model that provides the nanoparticle transmission rate in the compartment model is expressed as

r T x (t) = dC N P (t) dt = k d c in -k e C N P (t) , (1)
where C N P (t) is the nanoparticle concentration behavior along time, c in is the initial nanoparticle concentration, k d [min -1 ] and k e [h -1 ] are the first-order dissolution and elimination rate constants, respectively. The solution of (1) shows a faster increase in the concentration for higher values of dissolution constant, while it decreases very slowly due to typical value of elimination constant i.e., k e = ln(2)/t 1/2 , where t 1/2 [h] is the elimination half-life, that is the time required for the concentration of the nanoparticles to reach half of its original value (i.e., t 1/2 = 12 h).

The behavior of nanoparticle concentration in the compartment reflects that of a pulse-based modulation scheme [START_REF] Llatser | Diffusion-based channel characterization in molecular nanonetworks[END_REF], where a transmitter nanomachine instantaneously releases a pulse of molecules [START_REF] Nakano | Transmission rate control for molecular communication among biological nanomachines[END_REF]. A detailed description of the nanoparticle concentration behavior has previously been analysed in [START_REF] Loscrí | Modeling and experimental analysis of an in-body area nanonetwork[END_REF].

In a generic blood vessel, the nanoparticle transmission rate r T x (t) is linked to the nanoparticle delivery rate r Rx (t) through the following expression:

r Rx (t) = ∞ -∞ r T x (τ ) h (t, τ ) dτ , (2)
where h(t, τ ) is the time-varying impulse response of the MC link that takes into account for physicochemical processes. The analytical solutions of ( 2) can be obtained through the Harmonic Transfer Matrix method. Due to the fluctuations in the blood flow, the impulse response of the system depends on the state of the blood flow (local environment) at the time of the injection. The analytical expression of the time-varying impulse response of a MC link depends on (i) the apparent velocity, (ii) the effective diffusivity, and (iii) the reaction process. Finally, from [START_REF] Chahibi | Pharmacokinetic modeling and biodistribution estimation through the molecular communication paradigm[END_REF] we can derive the desired nanoparticle transmission rate r * T x , as

r * T x (t) = K i=1 r * T x,i • sinc t -iT s T s , ( 3
)
where K is the number of samples, and T s is the sampling period that satisfies the Nyquist criterion i.e., T s < (2B) -1 , with B the bandwidth of the time-varying impulse response of the system. Notice that the sampling period depends on the blood velocity and the characteristic time scale of the advection-diffusion process.

B. Nanoparticle diffusion process

The diffusion process is analysed by distinguishing two cases i.e., (i) the ideal, and (ii) non-ideal one. In the first scenario, the nanoparticle concentration is assumed as homogeneous and no nanoparticle is lost during the diffusion. On the other hand, in the non-ideal case a portion of nanoparticles is lost and cannot reach a destination point. As known, the reaction of the human immune system to the presence of nanoparticles can cause nanoparticle loss and errors in the diffusion and reception processes, respectively. A detailed study on nanoparticle loss in a nanoparticulate system is investigated in [START_REF] Loscrí | On the interaction between a nanoparticulate system and the human body in body area nanonetworks[END_REF].

In an ideal case, the concentration is assumed homogeneous and the residence time attains a mean reference value. Unfortunately, in a real reactor the nanoparticle fluid spends a different time inside the reactor, depending on specific characteristics of the compartment. The ideal case that models the compartment can be represented through a bioreactor. A bioreactor is a reactor that utilizes either a living organism or one or more enzymes from a living organism to accomplish a certain chemical transformation.

For the non-ideal case, from (1), the nanoparticle transmission rate r T x (t) can be identified with the nanoparticle concentration flux J T (x, t) at the output of the tablet i.e., for x = x T . The particle concentration flux J T (x, t) is dependent on the nanoparticle concentration gradient at time t and position x through the Fick's first law, as follows

J T (x, t) = -D∇C N P (x, t) , (4)
where D [cm2 /s] is the diffusion coefficient, assumed as a constant value for a given fluidic medium, and depending on the size and shape of nanoparticles, as well as the interaction with the solvent and viscosity of the solvent. Unfortunately, the Fick's first law works when applied to steady state systems, namely the concentration will keep constant both along the space and in the time. In our application, the concentration changes during the time, since nanoparticles diffuse along the space determining different levels of concentrations. For that, we need to consider the Fick's second law. In practice, the diffusion associated with the degradation kinetics yields to the following mass balance:

δC N P (x, t) δt = D δ 2 C N P (x, t) δx 2 + b • C N P (x, t) , ( 5
)
where b is a kinetic rate constant, and C N P is the drug concentration as transmitted from the previous phase. Due to the thinness of the wall as compared to the overall compartment radius, we can use Cartesian coordinates as approximation instead of cylindrical coordinates. We consider our compartment with a total volume V , and a flux F going through the two reactors. Then, we can apply and solve the mass balances that follow directly from [START_REF] Kumar | Handbook of Particulate Drug Delivery[END_REF]. The mass balance on the first reactor can be modeled as a first order differential equation, that is

dC 1 (t) dt = - 2F V + k C 1 (t) + 2F V + k C input (t), (6)
with the following conditions

C 1 (t = 0) = 0, C input (t) = C N P • δ(t). (7)
This leads to the solution for C 1 (t) as

C 1 (t) = C N P • e -( k+1 τ )t , (8)
where τ = V 2F . The quantity (C N P -C 1 (t)) corresponds to the portion of nanoparticle concentration that will be directly eliminated by the body, without reaching the receiver.

As an analogy to (6), we can write the following mass balance equation:

dC 2 (t) dt = - 2F V + k C 2 (t)+ 2F V + k •e -( k+1 τ )t , (9)
whose solution is

C 2 (t) = C N P • t τ • e -( k+1 τ )t , (10)
which represents the concentration of dissolved nanoparticles in the compartment.

As we have modeled a scenario as a fluidic medium where nanoparticles are free to move following the diffusion laws until reaching the target cells 2 , they are able to form chemical bonds with them. Thus, from [START_REF] Bhumkar | Chitosan reduced gold nanoparticles as novel carriers for transmucosal delivery of insulin[END_REF], we can obtain the concentration of bonds i.e., C b (t), formed due to the dissolved nanoparticles bound with the receptors, which can be described by the following formula:

C b (t) • u (t -δ) =    N B • 1 -e (-t-δ τ ) , t > δ 0, t ≤ δ (11)
where N B is the maximum number of bonds that can occur i.e., N B = max C 2 (t), τ [s] is the delay necessary for the bond formation, δ [s] is the start time of the reception process that is related to the diffusion delay of the nanoparticles, and u(t) is the Heaviside step function.

C. Nanoparticle reception process

In the reception process, a nanoparticle is received when it forms chemical bonds with the receptors of a target cell, following the ligand-receptor bond phenomenon.

Not all nanoparticles can form bonds, but just those that reached the location of a target cell. Indeed, we can distinguish (i) a portion of nanoparticles concentration able to reach a target cell (namely, the most resistant3 -MRnanoparticles), and (ii) the remaining part comprised of those nanoparticles that are directly eliminated by the elimination process, without reaching any target cell (namely, the less resistant -LR-nanoparticles) 4 . Indeed, the transmitter emits a flow of nanoparticles, which will diffuse in the medium. A few of them will have a most resistant behavior, and will be the dissolved nanoparticles (i.e., MR), while others will be the eliminated nanoparticles (i.e., LR). At the receiver side, only the MR nanoparticles will be received, while the LR nanoparticles will be eliminated.

In the capture process, we distinguish two cases for (i) ideal, and (ii) non-ideal channel. In the case of ideal channel, nanoparticles are emitted by the transmitter and are correctly bound by the receiver. This corresponds to no diffusion errors (e.g., no nanoparticle elimination), and no reception errors (e.g., no queuing delays at the receptors). On the other side, for the non-ideal channel, nanoparticles can be affected by diffusion errors (e.g., nanoparticles can be eliminated before reaching the receiver), or are not bound due to interfering nanoparticles (e.g., nanoparticles near the receptors that cause cross-talk and interference). As an instance, during the diffusion process, a few nanoparticles can be damaged by obstructions and other interfering molecules (e.g., the B-cells of the human immune system [START_REF]On the interaction between a nanoparticulate system and the human body in body area nanonetworks[END_REF]), with the consequence that those nanoparticles are eliminated by the body before reaching target cells.

Let us model the transmitter as a discrete memory-less source that emits nanoparticles, all potentially able to diffuse in the volume and reach the target cells. By assuming the channel model as a binary symmetric channel, the transmitter is modeled as emitting a binary variable X i with i = [START_REF] Svenson | Multifunctional Nanoparticles for Drug Delivery Applications: Imaging, Targeting, and Delivery[END_REF][START_REF] Freitas | What is nanomedicine?[END_REF], whose values are x 1 = 1, and x 2 = 0, associated to one MR, and one LR nanoparticle, respectively. Then, the probabilities of emitting the symbols x (1,2) are

P (X i ) = P (x 1 ) = p, P (x 2 ) = 1 -p. ( 12
)
The receiver can form binds only when a MR nanoparticle arrives. Then, the receiver can receive (i) one or (ii) no nanoparticle. The received signal can be expressed as a binary variable Y j with j = [START_REF] Svenson | Multifunctional Nanoparticles for Drug Delivery Applications: Imaging, Targeting, and Delivery[END_REF][START_REF] Freitas | What is nanomedicine?[END_REF], whose values are y 1 = 1, and y 2 = 0, respectively associated to one bond, and no bond.

The diffusion channel model is assumed as a binary symmetric channel. Also, we will distinguish between the ideal and non-ideal scenarios, respectively when the correct reception probability is maximum, and not.

In the case of ideal channel, we can calculate the following conditioned probabilities:

P ( y 1 | x 1 ) = 1, P ( y 1 | x 2 ) = 0, (13)
P ( y 2 | x 1 ) = 0, P ( y 2 | x 2 ) = 1, (14)
from which we can obtain the mutual information in the ideal case (i.e., I I ), as

I I (X i , Y j ) = i j P (x i ) P ( y j | x i ) log P ( y j | x i ) i P (x i ) P ( y j | x i ) , (15)
which simplified becomes

I I (X i , Y j ) = p log 1 p + (1 -p) log 1 (1 -p) , (16)
that represents the entropy at the transmitter. Finally, from ( 16), we can obtain the channel capacity in the case of ideal scenario as

C I = max p p log 1 p + (1 -p) log 1 (1 -p) . ( 17
)
Notice that (17) depends on the probability p of emitting one MR nanoparticle, whose behavior is intuitively decreasing when the nanoparticle concentration C N P (t) decreases as well. The expression of p can be formulated following the behavior of a low-pass filter in the frequency domain, that is

p (ω) = 1 1 + jωτ , (18)
where ω = 2πf [Hz], and τ [ms] is the time constant of the RC circuit. Notice that τ has lower values corresponding to higher probabilities of one MR emission, meaning that slower is the slope of |p(ω)|, faster is the increase of the nanoparticle concentration due to the emission of MR nanoparticles.

In the time domain, the probability p results:

p (t) = ≥ (1 -p) , for t ≤ t 1 , < (1 -p) , for t > t 1 , (19)
where t 1 is the time instant where the concentration of nanoparticles is maximum. Eq. ( 19) states that for t ≤ t 1 (i.e., for increasing values of C N P (t)), the probability of emitting an MR nanoparticle is greater than (or equal to) the probability of emitting a LR nanoparticle i.e., (1 -p), while for t > t 1 i.e., for decreasing values of C N P (t), the probability of emitting an MR nanoparticle results lower than that of emitting a LR nanoparticle. On the other side, the probability (1 -p) of emitting a LR nanoparticle is expected to increase when the overall nanoparticle concentration decreases, that is for t > t 1 .

Still referring to the circuit theory, it follows that the behavior of q = (1 -p) can be modeled as the charge of the capacitor C in RC circuit, and its analytic expression is Referring back to [START_REF] Nakano | Molecular communication among biological nanomachines: A layered architecture and research issues[END_REF], in the ideal scenario, the channel capacity can be expressed in terms of spectral efficiency [b/s/Hz], as shown in Fig. 1. This represents the information rate (i.e., the amount of nanoparticles in the time unit) that can be transmitted over a given bandwidth i.e., [1, 10 6 ] Hz. This is true since we have considered the system as a binary symmetric channel, when the nanoparticle emission/reception corresponds to bit emission/reception. Finally, the frequency spectrum considered in these analytic results ranges from 1 Hz to 1 MHz. Although the nanoparticles we are considering show size in the nanoscale level, corresponding to a frequency range in the THz band, we believe that the results in a lower frequency range could help the future development of nanoscale communication systems. Also, we do not consider a wider frequency range since such results up to 1 MHz already show clearly the trend of the spectra efficiency as a function of the frequency, where the peak of capacity can be easily shifted to higher frequencies. An analogous consideration has been adopted in [START_REF] Pierobon | A physical end-to-end model for molecular communication in nanonetworks[END_REF].

q (ω) = jωτ 1 + jωτ . ( 20
)
From Fig. 1, we observe that the three curves of capacity are obtained for different values of probability p. However, we notice the maximum values are the same, i.e. C = 0.69 [b/s], independently from the probability p, occurring for different values of frequency.

In the case of non-ideal channel, the system model can be represented as in Fig. 2, and the following conditioned probabilities hold:

P ( y 1 | x 1 ) = r, P ( y 1 | x 2 ) = e, ( 21
) P ( y 2 | x 1 ) = e, P ( y 2 | x 2 ) = r, (22)
where e = 1 -r i.e., with 0 < e < 1, and r i.e., with 0 < r < 1, are the error and correct reception probability, respectively. This case corresponds to the ideal channel when r = 1, and then, e = 0. Notice that the error probability e is when one of the following events occurs:

1) The transmitter emits one MR nanoparticle (i.e., X i = x 1 ), but it is not able to be bound at the receptor, and no bond is formed (i.e., Y i = y 2 ); 2) The transmitter emits one LR nanoparticle (i.e., X i = x 2 ), and the receiver notifies one bond has been formed (i.e., Y i = y 1 ). The first event depends on the errors during the nanoparticle diffusion process; as an instance, one MR nanoparticle arrives at the receiver but can form no bond. On the other side, in the second event, one bond is formed even if the transmitter has emitted one LR nanoparticle, which is expected to be eliminated by the body, and then should never reach the receptor. However, it could happen that in the very near field of the receptor, one interfering nanoparticle could form a "fake" bond.

The expression of the mutual information for the non-ideal channel (i.e., I N I ) is

I N I (X i , Y i ) = r log r + (1 -r) log (1 -r) + -(1 -p -r + 2rp) log (1 -p -r + 2rp) + -(p -2rp + r) log (p + r -2rp) . ( 23
I N I (X i , Y i ) = r log r + (1 -r) log (1 -r) + -η log η -(1 -η) log (1 -η) . ( 24
)
Notice that the meaning of η can be represented also as:

η = p 1 -2r + r p = pe + rq, (25)
where the first term pe represents the probability that one MR nanoparticle has been transmitted and an error has been notified at the receiver, while the term rq is the probability that one LR nanoparticle has been transmitted and a correct reception has occurred. Such considerations are true since the probability of emitting one MR/LR nanoparticle is independent on the error occurring at the receiver, but it only depends on the channel noise and obstructions. Thus, η represents the contributions of errors occurring in a nonideal channel. Finally, from [START_REF] Long | Titanium alloys in total joint replacementa materials science perspective[END_REF], we can obtain the channel capacity in the case of non-ideal scenario as

C N I = max I N I (X i , Y i ) = = max r,η [r log r + (1 -r) log(1 -r) -η log η -(1 -η) log(1 -η)]. (26)
Analogously to the case of ideal channel, the capacity still depends on the probability p of emitting one MR nanoparticle, and moreover it depends also on the probabilities r and η. Fig. 3 depict different curves of the channel capacity 5 , in the case of non-ideal channel, for different values of r and τ . In Fig. 3 (a), we observe high capacity for highest and lowest values of the couple of correct reception probability r, and time constant τ . This means that (i) for r = 0.8 and τ = 9 ms (i.e., green line) the correct reception probability is the highest but the lowest is the probability of MR nanoparticle emission, and (ii) for r = 0.2 and τ = 3 ms (i.e., black line) lowest is the correct reception probability but highest is the probability of MR nanoparticle emission. In these cases, the capacity results highest with frequency variations, due to different values of τ . In contrast, for the other cases (see red and blue lines), the capacity is strongly reduced, still with frequency shifts.

Again, Fig. 3 (b) shows similar behavior of capacity for different values of the couple (r, τ ). This states that the magnitude of the capacity does not depends on the events of emitting one MR or LR nanoparticle (i.e., the value of τ ), but only on the channel behavior (i.e., the probability of correct/wrong reception). Indeed, given a fixed value of τ , the higher values of capacity are obtained for r → 1 for r > 0.5, and for r → 0 for r < 0.5, while for r = 0.5 the capacity is null. Fig. 4 depicts such a behavior of a non-ideal channel for τ = 7 ms. The highest capacity is 0.368 [b/s] given by r = [0.1, 0.9].

In the theoretical derivation of the emission, diffusion and reception processes, we characterize the spatio/temporal evolution of the nanoparticles without taking into account specific features of the nanoparticles and the fluid properties and interactions where they are immersed. This theoretical evaluation needs to be supported by a practical evaluation that allows the analysis of these features that would be taken into account as corrective factors in the theoretical model. In the next section we will show how to derive and evaluate the main factors characterizing the particles and the fluid as a whole system. The diffusion of the TiO 2 particles is associated to the activation energy of the biological system.

III. IN-BODY MODELING: EXPERIMENTAL EVALUATION

AND CHARACTERIZATION In this section we will describe the details and features of the particles, and the solution considered to infer the main features of the interaction between particles and body-like fluid solution. Specifically, we will study the morphology of the particles and any pH variations of the considered solutions. This analysis will allow the validation of the theoretical approach as derived in the previous section. TiO 2 (anatase, powder, 99.99% purity; Sigma-Aldrich) and an aqueous solution of chlorides of sodium, potassium and calcium in the same concentrations as normal body fluids (Ringer solution, 7.5 ml lactic acid, 5.85 g NaCl, 300 ml H 2 O di grade 2 purity, and 700 ml H 2 O and regulation of the pH to 6.9 -7.0) were used for the experiments. It is worth to notice that the particles we considered to deal our experiments are µ -sized (i.e. 40 and 44µ m) because of the easier treatability and analysis of these particles. This solution is often used as a physiological solution for in vitro study of biomaterials due to its similarity to the body environment.

Two different TiO 2 powders of dissimilar particle sizes, namely 40 and 44 micron respectively, have been selected for the experiments. Investigations on the metallic particles and their influence on the physiological solution has been carried out aiming to comprehend how these particles can influence the interactions between the biological system and the specific therapeutic nanostructure. In particular, structural and morphological observation by Scanning Electron Microscopy (SEM) and X-Ray diffraction, thermal analysis using Differential Scanning Calorimetry (DSC) and the metal ion release evaluation by pH measurements have been performed on the initial TiO 2 particles and compared with data associated to samples after their permanence in simulated body fluids.

X-Ray diffraction patterns of the TiO 2 powders, in the initial condition and after their 14 days permanence in the physiological solution are shown in Fig. 5. Both X-Ray patterns related to the original powders show a strong diffraction peaks at 2θ = [25 • , 48 • ] indicating the presence of the anatase phase. All peaks are in good agreement with the standard spectrum (JCPDS no 84-1286). As reported, the diffraction pattern peak intensity of the TiO 2 increases with increasing particles size from 40 µm to 44 µm. In terms of crystal structure, anatase, have Ti in an octahedral coordination with respect to the O atoms. In this crystal structure, Ti 4+ is present as TiO 6 octahedra and crystallize in a tetragonal unit cell. The development of monoclinic Titanium Hydrogen Oxide was observed as evidenced in Fig. 5 (dashed line ellipse), because of their permanence in the physiological solution.

The chemical bond established between the TiO 2 particles and O and H atoms from the aqueous solution results in an un-stable structure, making the hydrophilic powders more reactive towards any possible chemical compound, and suitable for drug delivery with a correct ability of controlled release for a prolonged period.

In line with some literature data [START_REF] Wang | Al2O3 composite agent effects on phase transformation of nanometer TiO2 powder[END_REF], [START_REF] Huberty | Kinetics study on phase transformation from titania polymorph brookite to rutile[END_REF], our DSC study indicates that at high temperature, phase transformation process occurs, and the exothermally and irreversibly transformation of anatase to rutile takes place, for the starting TiO 2 powder with a significant reorganization of the structure. This transformation does not affect the considered in-body system, since it arises at higher temperature level that human body can be reals, as reported in the DSC thermograms of the TiO 2 particles at 44 µm, in Fig. 6 (a), but some information can be deduced concerning the necessary minimum energy to start a chemical reaction, or to reach a transition state in the case of drug transport and administration.

DSC studies were carried out to confirm the stability of the powders in the interest temperature range for the human body and to collect information about the TiO 2 particles diffusion velocity in the biological environment by analyzing the activation energy of the system. The most important factors that influence the velocity of the reaction are (i) the nature and the concentration of the TiO 2 and of the therapeutic particles, and (ii) the temperature. Proportionally to the increase of the reagents concentration the probability of the collisions and the velocity of the particles increases; higher surface contact between the particles favors higher reaction rate, while higher temperature leads obtaining more collisions between the particles and the velocity of the reaction become higher.

Calculations have been performed to estimate the kinetic parameter as activation energy and to qualitatively correlate it to the rate of the reaction. The activation energy is very low (i.e., E a ∼ 11.65 kJ/mol) and, according to the metallic ion release measurements, no any chemical interaction between the TiO 2 particles and the biological solution has been obtained. The activation energy will increase when anchoring the therapeutic particles to the TiO 2 particles before immersing them in the biological fluid. There are ample space to the control of the reaction between TiO 2 particles and the therapeutic particles in the preferred way according to the targeted application, i.e., selection of the proper drug and its quantity for the given treatement.

The relationship between activation energy, E a [J mol -1 ], and the velocity of a chemical reaction is provided by Arrhenius equation i.e.,

E a = -RT • ln k A , (27)
where k is a reaction rate constant (measured in s -1 for first order reactions), R is the universal gas constant (i.e., 8.314472 [J K -1 mol -1 ]), A is the pre-exponential factor (measured in [s -1 ] for first order reactions), and T is the temperature [K]. The inverse exponential relationship between activation energy and the rate constant guarantees that the reactions with a very high activation energy will have a very low reaction rate. As activation energy decreases, the reaction rate increases. The activation energy is determined by Kissinger's method i.e., with no precise knowledge of the mechanism of the reaction, the following equation can be used:

ln β T 2 p = ln AR E a + ln n(1 -α) n-1 - E a RT p , (28)
where T p [K] is the temperature corresponding to the maximum reaction rate (peak), α is the conversion at T p , n is the reaction order, and β is the heating rate expressed in [K s -1 ]. Considering Kissinger's approximation, it follows:

f (α max ) = n(1 -α max ) n-1 ∼ = const. (29)
The activation energy can be determined from the plot of ln β T 2 p versus 1 Tp , as depicted in Fig. 6 (b). The pH of the solutions containing the TiO 2 powders was measured at the pre-set time intervals during 14 days. The quantity of metal ions released in the physiological solution is negligible even after 14 days: the pH value of the solutions remains constant. The results obtained for the pH value and the weight loss fulfill the conditions required by the Standard ISO 10271/2011 concerning the evaluation of the corrosion resistance of the materials used in bio environment.

The particles shape and their surface reactivity influence the transport properties of other particles in the human environment, and thus affecting the adhesion kintetics of the therapeutic particles loaded on and their transfer to the favorite position. As illustrated in Fig. 7, the TiO 2 particles show a controlled size distribution even if not perfectly regular as their size concerns. This aspect can be capitalized to improve the drug transport and their delivery efficiency as compared to the identical spherical shape particles. After their permanence in the physiological solution, some cluster development has been observed with increased surface area. This configuration highlights the positive effect coming from the permanence in the biological solution favoring the most efficient loading of the therapeutic particles obtaining higher attachment to the specific therapeutic particles as a vascular barrier.

IV. CONCLUSIONS Results of investigation on how nanoparticles behave in the human body for nanomedicine applications have been presented. The action is described by means of the modeling of the emission, diffusion and reception processes, which represent the overall end-to-end system from a transmitter to a receiver. In particular, the one compartment model for oral drug administration has been presented and discussed.

From the characterization of the DDS channel we derived the capacity both in case of ideal and non-ideal scenario. Specifically, TiO 2 particles in a biological-like fluid system as possible carrier to sustain drugs has further been considered.

Experimental results on their medium-time presence in biological-like fluids confirm their stability within the system, and put in evidence their capability to be used as carrier for drug delivery. The results of the investigation make evident the possibility of combining the biocompatibility of TiO 2 to the drug delivery features and their use in biomedical field. The observed complete absence of any release of Ti ions in the physiological solution demonstrates, once again, a non-toxic character of the considered molecule. The particles with a high surface area show a higher tendency to be wetted by the aqueous biological solution and they can support more efficiently any drug loaded on their surfaces.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Capacity [b/s] of an ideal channel, for different values of frequency. Different curves correspond to different values of probability p, again depending on the time constant τ .

rrFig. 3 .

 3 Fig. 3. Capacity [b/s] of a non-ideal channel (i.e., r = 1). Different curves correspond to different values of probability r and τ .

  ) Let us pose (p + r -2rp) = η, then (23) becomes

Fig. 4 .

 4 Fig. 4. Capacity [b/s] of a non-ideal channel for a fixed value of τ [ms] and different values of r.

Fig. 5 .

 5 Fig. 5. X-Ray diffraction patterns for the TiO 2 powders of both sizes (i.e., 40 and 44 micron): the initial powders, and after their permanence for 14 days in the physiological solution (labelled as "treated").

Fig. 6 .

 6 Fig. 6. (a) Heat flow curves of the TiO 2 particles at 44µm, obtained at two heating rates. (b) Plot of ln(β/Tp) vs. 10 3 /Tp for calculations of the activation energy based on the heating rate β of the TiO 2 particles.

Fig. 7 .

 7 Fig. 7. SEM microstructure of TiO 2 particles for different states and size i.e., (a) initial state and 40µm size, (b) initial state and 44µm size, (c) in solution and 40µm size, and (d) in solution and 44µm size.

In this paper, the terms emission and transmission are interchanged.

As an instance, a target cell is a tumor cell that has been previously detected.

The term "resistant" means the skill of nanoparticles to diffuse in the biological fluid, and then reach a target cell.

Notice that also the MR nanoparticles will be eliminated by biodegradation process, after having absolved the drug delivery process.

The channel capacity [b/s] versus frequency represents the spectral efficiency [b/s/Hz].