Evaluation and comparison of inter-processor communication techniques in model-based design flows/tools

Transcription

1 Evaluation and comparison of inter-processor communication techniques in model-based design flows/tools Pratiksha Dilip Deshmukh Computer Science in Applications Embedded Systems Group Technical University of Kaiserslautern Kaiserslautern, Germany Abstract Model-based design provides an efficient approach to establish a common framework for communication throughout the design process supporting the development cycle. It has many advantages over traditional sequential design approach. Instead of using complex structure and extensive software code, the model-based design can be used to define models with advanced functional characteristics. It increases the level of abstraction. The generated software through model-based design is then deployed onto real heterogeneous platform with some specific MoC. It verifies the generated software for any design disturbance and to remove it. With the help of above advantages of model-based design, it seems more helpful to study the communication between two components of a distributed system. For example, the Inter-processor communication in a distributed system comprises of a number of processing elements which are interconnected with a frame to transmit data or sharing resources with each other. Over the communication synthesis stage of the inter-processor communication, the scheduling code for inter-partition communication or the interfaces for the ease of communication between two components are automatically added to the design. This scheduling code or interfaces serve as a bridge between the partitions or interface. Model-based design can be used to study the communication synthesis to simplify the complex structure. This paper presents the study and comparison of three of the inter-processor communication techniques such as Interface Wrapper, Ptolemy II and Virtual Function Bus with respect to model-based design flows/tools. These inter-processor communication techniques are based upon different MoCs and communication synthesis methods over heterogeneous platform. 1 Introduction Model-based design is a mathematical and visual method of addressing problems associated with designing complex control, signal processing and communication systems[3]. It provides an efficient approach to establish a common framework throughout the design process. The models built using model-based design lead to rapid prototyping, software testing and verification. Model-based design is also proved efficient to study the inter-processor communication over distributed systems. In a distributed system, e.g. multi-core processor, a single computing component contains two or more independent processing units. In heterogeneous system contain two or more processors or cores. These systems are designed to run multiple instructions at the same time. Inter-processor communication is a set of methods To appear in EPTCS.

2 2 [Pratiksha Dilip Deshmukh] of exchanging data between two or more processing elements in multicore processors and between two or more processors in heterogeneous systems re-configurable hardware platform. [12]. Semantics is also an important part in the interaction between different components in heterogeneous platform. Semantics roughly means what the design means and how it actually works. Incompatibility and inconsistency can arise when a component is used in domain for which it is not originally designed. Domain defines the laws of concurrent interaction between different components. A collection of such rules is called as Models of Computation (MoC). The MoC specifies what constitute a component, execution and concurrency mechanism and communication mechanism. Depending upon the passive way to activate the component in the communication, the MoCs can be event driven, data-flow driven, and time driven and custom ones. Hence, with the help of the abstraction approach of model-based design and MoC, different inter-processor communication can be evaluated for compatibility and consistency. The model-based design flows are developed for abstraction based on different MoCs.The design flow for the inter-processor communication model for hardware and software subsystem over heterogeneous platform consists out of overall design steps like simulation, verification, mapping, communication refinement and synthesis. This will generate the final executable code which is deployed over the multiprocessor platform. A model-based design abstraction for Inter-processor communication is as shown in figure 1 below. The application behavior of the model based design flow can be explained with the help of different behavior model. In the following example we have considered the dataflow behavior model to give view of the application behavior of the model-based design flows. Here the vertices represent the computational units while the edges represent the connecting unidirectional buffer. In the partitioned model, the computational units are assigned to different Processing elements (PEs). Final but most important stage in the proposed design flow is the System and Communication Refinement phase. In this stage, all the processing elements communicate with each other with the help of different MoC or bus systems, for instance CAN, FlexRay, etc. and the information regarding communication is integrated with the designed abstraction. Here the automatic generation of code for the inter-partition or interface communication takes place. Interfaces are also inserted into the design for the hardware synthesis. This stage is called as the communication synthesis phase. This stage is different in different design flows. The main purpose of this topic is to study different communication technique and to come to a conclusion with the comparison among them with the help of model-based design. Figure 1: model-based design flow abstraction of Inter-Processor Communication The article is structured as follows: Section 2 illustrate the overview of the design flow of three inter-process communication technique used in 2.1Interface Wrapper[15] which intends to address some of the limitation present in supporting hardware and software synthesis of the same source code with

3 [Inter-Processor Communication Techniques Evaluation and Comparison] 3 the software that scales on multicore platforms, 2.2 Ptolemy II [14] which is an open-source simulation and modeling tool intended for experimenting with system design techniques, particularly those that involve combinations of different types of models and finally 2.3 Virtual function bus [13] which is logical entity that facilitates the concept of relocatability within the AUTOSAR software architecture by providing a virtual infrastructure that is independent from any actual underlying infrastructure and provides all services required for a virtual interaction between AUTOSAR components with respect to model-based design. Section 3 introduces the Communication Refinement used in the design flow which is responsible for the Partitioning of the dataflow program, interconnection of different hardware and between hardware and software. Section 4 explains the comparison between the Communication Refinement stage of the three inter-processor communication technique used as Interface Wrapper, Ptolemy II and Virtual Function Bus (VFB) respectively with respect to section 3. Finally section 5 concludes the paper by discussing the advantages of the approach. 2 The Design flows Before evaluation and comparison of the communication synthesis and inter-processor communication techniques of a distributed system, it is important to study the design flow of the system to know about the domain and in turn the laws of concurrent interaction which are designed originally. The selection of MoC for a system is also depending upon the system architecture. For example, in interface wrapper the architecture is divided into dataflow models. Design flow also gives s the view of the functional design which is the process of translating the initial system concept into an actual implementation that performs the required function. Following Section gives an overview of the design flow of three inter-process communication technique used in Interface Wrapper, Ptolemy II and Virtual Function Bus. This section intends to address the system design architecture and MoCs supporting these inter-processor communication techniques. 2.1 Interface Wrapper : Interface Wrapper is an inter-processor communication technique used for Hardware-Software synthesis over distributed platform especially heterogeneous platform. Over a heterogeneous platform, the architecture is divided into a dataflow models. These DPN models are then simulated and assigned to different PEs with partitioning. To obtain the communications over these partitions, Interface wrapper uses PCI Express and Ethernet. The design flow for the Hardware-software synthesis over heterogeneous platform consists of four steps as illustrated as shown in figure 2. It consists of five steps which includes Architecture and application level modeling, simulation, profiling, partitioning, scheduling, communication synthesis and finally generation of the source code. These steps are explained in detail as below: Stage.1: Application and Architecture Model: It is the stage of specification of the application and the definition of platform architecture. The application model uses the elementary dataflow program that uses a directed graph. In these directed graphs, the vertices represent computational units or actors and the edges represent the stream of data. The dataflow program language[8] used resembles more to Kahn model semantic. A simple dataflow program as a graph is as shown in figure 3 where the circle represents the computational units or actors while the connecting edges represent the connecting link between computational units or the stream of data. Interface Wrapper uses the model with an extension to the dataflow MoC. In this DPN MoC, vertices

4 4 [Pratiksha Dilip Deshmukh] Figure 2: The Design-Flow for Hardware-Software synthesis over heterogeneous platform Figure 3: Dataflow program as graph or actors executes through computational steps or firings. During a firing, actor may take data from the input edge and produce data on output edge and these results in change of internal state. The firing rule is associated with each firing function which corresponds to a particular pattern matching on the input

5 [Inter-Processor Communication Techniques Evaluation and Comparison] 5 edge and the current internal state. The firing occurs only when data is available on the input stream. One important characteristic of all dataflow models is that individual actor preserves their own state and does not share memory with each other. It uses CAL (Cal Actor Language)[9] which is a domain-specific language which helps to analyze actors and determination of associated MoCs which is a property for efficient optimization in code generation. Static scheduling by correct-by construction sequence of firing can be an example of such optimization. The Architecture model used in Interface Wrapper is based upon the System-Level Architecture Model. This architecture is a unidirectional graph where each vertex represents a processing element e.g. CPU of FPGA (Field-Programmable Gate Array)[2] and edges represents links as transfer of data to and from operator. Figure 4: Mapping initial application graph. The model is sequential and permits to describe architecture with different levels. For example, multicore processor can be represented as a single level, where all the lower level details will be represented as vertex and point-to-point connection. Stage 2: Simulation, Co-verification and Profiling : In the second stage the application is validated for functionality using simulation. It also provides the input for the profiling stage. In this stage, the simulation of the dataflow graph of CAL is interpreted using an interpreter supported by RVC-CAL. It is a part of the Open RVC-CAL Compiler with infrastructure dedicated to RVC-CAL language. This interpreter simulates the intermediate representation of each actor transformed by the front end of ORCC [4].A profiler is also build over interpreter to extract the high-level metric during the execution of dataflow program simulation. The aim of the simulation and profiling is to calculate the complexity of the actors. The complexity can be calculated by counting the number of instructions and operators used in expressions. The relative bandwidth of FIFOs is extracted in the profiling stage by counting number and size of data exchanged during execution. Stage 3: Space Exploration : Partitioning : This stage provides the mapping of the algorithm onto the architecture. It can be obtained by partitioning and scheduling of the dataflow program. Partitioning includes tasks such as assignment of processing element (PE) for each actor in the dataflow program while scheduling orders the execution order of actors. The numbers of processing elements are kept lower than the number of dataflow actors to imply that more than one actor can be assigned to a single processing unit. The mapping of the application graph is shown in Figure 4.Here the each color represents the allocation of the actor to a particular processing element. An example of partitioning of a CAL dataflow program is explained in figure 5. Here, simulations are made to find the correct par-

6 6 [Pratiksha Dilip Deshmukh] tition with insertion of wrappers and actors which represent the behavior of the interfaces included in the architecture. A request to rewrite the CAL program is made in case of no partition condition. After the validation of architecture for partitions, attributes are added in correspondence with the Hardware and software components. This is the stage where the Interface Wrapper is added to the design which becomes functional in communication synthesis phase. Once the choice of the actors is made, each part is translated for FPGAs using CAL2HDL and for processors using CAL2C. Figure 5: Example of partitioning of Data-flow graph Figure 6: Scheduling of Data-flow graph Scheduling : There are several possible ways for scheduling of the dataflow graph. Once the partitioning is decided, scheduling of the execution order of the actors over a particular Processing Element (PE) starts. There is no need of particular scheduling strategies because actors assigned to different PE

7 [Inter-Processor Communication Techniques Evaluation and Comparison] 7 can run in parallel. Scheduling is necessary when the numbers of actors assigned to a Processing Element (PE) are more than one. The execution list of order of execution of the actor is generated at compile time and run time. The compile time execution of actor scheduling is termed as Static Scheduling while the run time scheduling is termed as Dynamic Scheduling. The scheduling is shown in figure 6 where different colors represent allocation to different processing elements (PEs). Stage 4: Communication Synthesis : The automatic addition of scheduling code needed for interpartition communication and interfaces for communication between components takes place in this stage. This insertion will be considered later during the synthesis phase which is discussed in section 3. Stage 5: Code Generation : This stage is comprised of picking of all the partitioned of the architecture with the interconnection that are necessary for the communication across the partition to generate the corresponding source code. Once the choice of the actors is made for the partition, each part is translated into the correct language by two tools: CAL2HDL for FPGAs and CAL2C for processors. Finally the generated source code is compiled using the native compilers. 2.2 Ptolemy II The Ptolemy II studies modeling, simulation, and design of concurrent, real-time, embedded systems. The focus is on assembly of concurrent components and Cyber-Physical System (CPS)[11], which combine computing and network with physical dynamics. It uses well-defined MoC that supports the interaction between components in a sequential multi-processor design environment. One of the results of the Ptolemy II includes parallel scheduling technique and optimizing inter-processor communications in parallel implementations. It is an open-source modeling and simulation tool. The key goal of Ptolemy II to minimize the accidental differences in syntax, semantics, and pragmatics between domains, and maximize the interoperability of designs expressed in different domains. Ptolemy II relates four distinct classes of syntaxes i.e. block diagrams, bubble-and-arc diagrams, imperative programs, and arithmetic expressions. These different syntaxes allow Ptolemy to deal with various design domains. For example, Block diagram are used to explain the concurrent composition of communicating components. It also integrates number of semantic domains. It is designed to support specification type of interaction between components in design such as type of interaction, type of message and type of communication etc. Domains and Model of Computation : The semantic domain of the Ptolemy II deals with the laws for interaction between components. These rules are called as MoC.The rules that constitute the MoC are subdivided into three categories. First set of rules specify the constitution of a component, the second one specify the execution and concurrency mechanism and the third category specifies the communication mechanism. To support the heterogeneous platform, these MoC supports each other for concurrent execution. The Roles of Models in Design : There are three major parts of process implementing systems in Ptolemy i.e. Modeling, Design and Simulation as shown in figure 7. Figure 6 gives the diagrammatic representation of the co-relation and inter-dependence between the modeling, design and simulation stage. Modeling imitates the system to reflect the properties. Models help to get a deeper understanding of a system. Design is a systematic creation component to achieve the desired functionality. Simulation focuses on the question that how a model will behave in a particular environment. Simulation is a prerequisite for the testing phase of the design to check the in-order functioning.

8 8 [Pratiksha Dilip Deshmukh] Finally the analysis phase of the design gives the deeper understanding of the functionality through the individual study of the components. Figure 7: The roles of models in design Actor Models : Ptolemy II supports the modeling of heterogeneous systems by using a hierarchical component-based architecture and well-defined MoC computation. The basic component of this architecture is called an actor. Actors are components that execute concurrently and share data with each other by sending messages via ports. A simple actor model is shown in figure 8. In figure 7, actor A communicates with actor B and C via ports with the help of a relation link to share data and resources concurrently. Figure 8: Simple actor model

9 [Inter-Processor Communication Techniques Evaluation and Comparison] 9 A Model of Computation with Push and Pull Processing: Push-Pull Model : A model of computation describes how components in a concurrent system can communicate and compute data. Different systems may desire different MoCs and some complex systems need more than one MoC. The execution of MoCs usually starts from the data source or event source and propagates to downstream components. It supports heterogeneous mix of MoCs. Push-Pull model of communication is one of the many MoCs used in Ptolemy II for component interaction. It supports a mixture of data-driven and demand-driven communications. Push represents message transfer that is initiated by the producer. On the contrast, Pull represents message transfer that is initiated by the consumer. This MoC has been implemented as the Component Interaction (CI) domain in Ptolemy II, a hierarchical and heterogeneous modeling environment. 2.3 Virtual Function Bus The AUTOSAR [1] software architecture is an open standard automotive software architecture that has been developed by a joint group of automotive vendors and stakeholders in order to create an integrated standard infrastructure for vehicle software development. The basic principle of AUTOSAR software is to design the relocatability of components among different architectures. AUTOSAR uses a three-layered architecture: Basic Software: Its a standardized functional module in AUTOSAR without any dedicated work but serve as a service provider that are necessary to run the functional part of the upper software layer. Runtime environment : It consists of the middleware which is used to abstract the network-topology for the inter- and intra-ecu information exchange between the components of application software and between the basic software and the applications respectively. Application Layer : It consists of the software components that interact at runtime. Visual representation of the AUTOSAR Architecture is as shown in Figure 9. In order to achieve a high degree of transparency against the underlying hardware infrastructures; the AUTOSAR standard introduces Virtual Function Bus (VFB) as architectural concepts. Figure 8 shows the AUTOSAR architecture in brief. The AUTOSAR software components are connected to the operating system, other system services and AUTOSAR Real-Time Environment (RTE) via a logical connection platform called as Virtual Function Bus (VFB). Virtual Function Bus: The virtual function bus[5] can be described as a system modeling and communication concept. It is logical entity that facilitates the concept of relocatability within the AUTOSAR software architecture by providing a virtual infrastructure that is independent from any actual underlying infrastructure and provides all services required for a virtual interaction between AUTOSAR components. In order to fulfill the goal of transferability, AUTOSAR defines a layered SW architecture and a formal description language for Software Components so that these components can be implemented independently from the underlying hardware. Due to this abstraction a virtual function bus can be used to assemble and integrate these components to a virtual AUTOSAR system and to verify the consistency of the communication relationship between software

10 10 [Pratiksha Dilip Deshmukh] Figure 9: AUTOSAR Architecture 3 Communication Synthesis After the mapping of the components to different processing elements in communication interface synthesis, some more transformations are needed for the interaction between the components to take place. These transformations are done in the communication synthesis phase with the addition of the scheduling code for the communication across the partition and interfaces which serve as communication link between components. Communication synthesis or semantics is an important part of study of inter-processor communication techniques. It gives the view of the design flow and interaction between different components. The rules for the interaction are called as Model of Computation (MoC). Here, Communication synthesis section discusses the inter-processor communication techniques used in Interface Wrapper, Ptolemy II and VFB for the communication between different components. The communication over components varies according to the architecture of the platform, MoCs used and component interaction model used. Subsequent section discusses the communication synthesis for Interface Wrapper, Ptolemy II and VFB in detail. 3.1 Interface-Wrapper The main objective of the communication synthesis in interface-wrapper is to develop a methodology for a unified specification for mapping of the hardware-software components onto a heterogeneous platform using dataflow model based on CAL language. The CAL based design flow is already explained in section 2.1.

11 [Inter-Processor Communication Techniques Evaluation and Comparison] Partitioning with addition of Communication Wrapper : During the partitioning phase of CAL model [16], Interface Wrapper are added to the design. The wrappers are defined with respect to the interface present in the platform. The Wrapper structure is designed to handle the integration of large variety of interfaces. It is composed of a generic part to handle the interface interconnections and an adapter which is specific for each interface. The wrapper does not have any effect on performance of the micro-controller used in adapter. Figure 10 shows the example of partitioning with the addition of communication wrapper for each external interface. Figure 10: Example of Partitioning with addition of Interface Wrapper CAL Wrapper Overview : An interface wrapper or communication wrapper is used to connect the interfaces to connect the devices. In partitioned CAL dataflow, the parameters change is required only for the right adapter. Figure 11 gives an overview of the interface wrapper ob the hardware side. The wrapper must be able to serialize the data from channels and de-serialize the data to the proper channel with the help of serializer and de-serializer Automatic communication interface synthesis : The algorithm and architecture mapping phase along with partitioning and scheduling result into a transformed dataflow graph. But in order to exhibit the communications across the partitions, some more transformations need to be applied over the dataflow graph. These transformations include insertion of additional vertices to represent the communication between partitions. This communication uses the appropriate MoC between different Processing Elements (PEs). The selection of these MoCs depends upon the architecture. Such transformation adds some vertices or actors in the dataflow graph which will help for (de) serialization of data and inclusion of interfaces between partitions in dataflow graph. The aim of the process of serialization is to schedule the communication between that is allocated on different partitions

12 12 [Pratiksha Dilip Deshmukh] Figure 11: Overview of Interface Wrapper on hardware side at runtime. The fact is that when several edges from the dataflow graph are associated to a single medium of the architecture, data need to be interlaced in order to be able to share the same underlying medium. In this case, to emulate the history of FIFOs in order to schedule data in the serialization, virtual FIFOs are used to connect the serializer to the actors on the sender side. On contrary with respect to traditional FIFOs that store data and maintain the state i.e. read/write counters, virtual FIFOs maintains the state while data are directly stored into a single FIFO from the incoming actor. Data is scheduled by the actors without any specific scheduling strategy. To retrieve the data on the receiver side, a header is places at the beginning of each data that defines the destination FIFO and the size of the payload illustrated as in figure 12. Figure 12: Header and Payload of stored data in Serialization FIFO Figure 13. Illustrates the insertion of the serializer vertex between the blue partitions which is connected to the red partition with two outgoing FIFOs. This reconfigurable hardware and multi-processor platform can use various inter-process communication methods through various physical/logical interconnections (PCI Express, Ethernet, etc.) to implement the interaction between PEs.

13 [Inter-Processor Communication Techniques Evaluation and Comparison] 13 Figure 13: Insertion of Serializer vertex 3.2 Ptolemy II Ptolemy Director : Ptolemy II supports the modeling of heterogeneous systems by using a hierarchical component-based architecture and well-defined MoC. Actor is the basic component. The interaction between actors within a composite actor is defined by a MoC and implemented by a director of that composite actor. The semantics of a model is not determined by the framework, but rather by software component in the model called a director, which implements a MoC. In Ptolemy II, director can tuned to different MoCs and each director represents a particular MoC on domain. Component Interaction Model is one of the examples of such domain on MoC. Component Interaction (CI) domain in Ptolemy II, a hierarchical and heterogeneous modeling environment uses MoC that supports Push-Pull communication between software components. It supports a mixture of data-driven and demand-driven communications. Push represents message transfer that is initiated by the producer. On the contrast, Pull represents message transfer that is initiated by the consumer. This MoC has been implemented as the Component Interaction (CI) domain in Ptolemy II, a hierarchical and heterogeneous modeling environment Component Interaction model : An actor encapsulates its computation and internal state. It interacts with its environment and other actors via a well-defined interface, which includes ports and parameters. Ports represent the points of communication. Parameters are used to configure the computation of an actor. And the channel of communication between actors is implemented by a receiver object contained by ports. A receiver defines the communication protocol between actors. The director defines the ordering of actor execution. A MoC is implemented by a particular director and receiver. The component interaction models uses push-pull model of communication. Ports, connections and actors serve as the basic component of this models which are explained in detail below: Push port vs. pull port : Each port contains an attribute named push/pull, which can be configured with three possible values: push, pull and agnostic. A port is a push port if the attribute is set to push, and is a pull port if the attribute

14 14 [Pratiksha Dilip Deshmukh] is set to pull. An agnostic port can be either push or pull. The exact type is resolved according to its connected ports with the assumption that connected ports have to be the same type Push connection vs. pull connection : The type of a connection is defined by the two ports at its endpoints. A connection is push type if it connects two push ports; a connection is pull type if it connects two pull ports Passive vs. active actors : The push-pull model classifies actors as two kinds, passive actors and active actors. Passive actors include Source actors, Sink actors, actors with pull inputs and pull outputs, actors with push inputs and push outputs and queue actors. Active actors include those that can either initiate production of data or can pull requests, such as Source actors with push outputs, sink actors with pull inputs and schedule actors. The difference between Passive Vs. active actors is also explain in figure 14 below. Figure 14: Passive Vs.Active actors Operational Semantics : The push-pull model follows multi-threaded execution. Here only actors posses its own thread of execution. All the passive actors share a single thread managed by the director which schedules them to execute. From above, we can say that execution of the push-pull model uses both process-based and scheduler based approach. The operational semantics for three types of active actors are explained as below: 1. An active actor fires with some frequency or according to an interrupt or event arrival. When an actor fires, pushing of data to its connected downstream actor takes place. This pushing of data causes the downstream actor to be enqueued into AsynchronousPushedActors queue.

15 [Inter-Processor Communication Techniques Evaluation and Comparison] An active sink actor fires only when it is ready to process the data. While firing, it issues a pull request for connection to its upstream actor. This connection with the upstream actor causes it to be enqueued to the AsynchronousPulledActors queue. It waits until the request is satisfied and then continues to process it. 3. A schedule actor models a component that can control the time and target to distribute data with the help of pull inputs and push outputs. When a schedule actor fire, it requests data from some of its connected upstream actors and wait until the data is ready, and then pushes the token to its connected downstream actors. Firstly, the upstream actors is to be added to Asynchronous- PulledActors queue and the second step causes the downstream actors be added to the AsynchronousPushedActors queue. In contradiction with active actors, the execution of passive actors is controlled by the director. Another possible approach of executing passive actors is to execute them in the calling thread of the active actor. The semantics can be better understood with the help of an example. Figure 15 shows a simple router model that consists of a FromDevice actor which listens to input network interface and outputs the received data. The identification and classification of data into three different queues is done by the Classifier actor. The ToDevice actor requests data when it is notified to fill the output network interface and The RoundRoubinSelector select data from the three queues according to the round-roubin algorithm when the ToDevice actor request data. In this model, FromDevice and ToDevice are the active actors. At the beginning, FromDevice has no data to output and waits for input and ToDevice requests data. The RoundRoubinSelector is added to the AsynchronousPulledActors queue and director is ready to handle the request. The RoundRoubinSelector waits for the data from first input. Due to unavailability of data, it then requests to queue 1. Queue 1 has no data. As Queue1 is a queue actor with push input, the propagation interrupted. Now assume that FromDevice receives input and fires. This causes the Classifier to be added into AsynchronousPushedActors queue. The Director become active and fires the Classifier actor and data is sent to Queue 1 and it will be triggered to fire. Here the data is first enqueued and checked whether any request is waiting for data which in turn call the director to fire again and satisfy it. Finally the RoundRoubinSelector is activated to fire and sends data to the ToDevice actor. This execution will continue with new data arrival and firing requests. 3.3 Virtual Function Bus In AUTOSAR, the most important concept is the hierarchical classification, which is fundamental to the AUTOSAR. These different layers have different missions and implement different functions. Each layer uses the interface provided by the layer underneath. In section 2.3, we have already discussed the basic concept of Virtual Function Bus and the software component view of AUTOSAR Communication Paradigm : The central structure in AUTOSAR has well-defined ports, through which component can interact with each other. AUTOSAR interface defines the services or data that can be provided or required by a port of a component. The AUTOSAR interface can be of two types i.e. Client-Server Interface or Sender-Receiver Interface. Client-Server Interface model is the widely used communication model in

16 16 [Pratiksha Dilip Deshmukh] Figure 15: Simple Router Model distributed systems while Sender-Receiver Interface model gives solution to the asynchronous distribution of information where a sender sends the information to one or many receivers. Both communication models are supported by AUTOSAR but there are some differences such as the content, the multiplicity, concurrency and ordering, etc. These interface models are explained in details as below: Figure 16: Client-Server Communication 1.Client-Server Communication : It is a widely used communication pattern in distributed systems. Here the server is a provider of a service and the client is a user of a service. The client initiates the communication, requesting that the server performs a service, transferring a parameter set if necessary. The server waits for the incoming communication requests from a client, performs the requested service, and dispatches a response to the clients request. The direction of the initiation of the request can be used to identify the sender and the receiver. A single component can be both a sender and a receiver depending on the server realization. The client can be blocked i.e. Syn-

17 [Inter-Processor Communication Techniques Evaluation and Comparison] 17 chronous Communication or non-blocked i.e. asynchronous communication after the initiation of the service request until the arrival of the response. The image gives a view of the client-server communication modeling according to AUTOSAR VFB View. Figure 17: Sender-Receiver Communication 2.Sender-Receiver Communication : The sender-receiver pattern gives solution to the asynchronous distribution of information, where a sender distributes information to one or several receivers. The sender is not blocked (asynchronous communication) and neither expects nor gets a response from the receivers (data or control flow), i.e. the sender just provides the information and the receivers decides autonomously when and how to use this information. It is the responsibility of the communication infrastructure to distribute the information. The image illustrates the sender-receiver Communication modeling in AUTOSAR VFB view. With the help of explicit COMPASS component model on Virtual Function bus, abstract Superclass ExplicitConnector is specialized with two abstract classes, class ClientServerConnector and class SenderReceiverConnector Virtual Function Bus at Application Level AUTOSAR defines Software Components (SWCs) as the application software that runs on the ECU. In AUTOSAR, software components make up the technology that hosts the application software. A software component is an abstraction that allows parts of application software functionality to be encapsulated. The encapsulation reduces the component dependence on the environment. VFB acts as the logic abstraction of the basic software and hardware layer. It is the sum of all communication mechanisms (and interfaces to the basic software) provided by AUTOSAR on an abstract (technology independent) level. When the connections for a concrete system are defined, the VFB allows a virtual integration in an early development phase. AUTOSAR Architecture System Constraint and ECU Descriptions In order to integrate AUTOSAR SW-Components into a network of ECUs, AUTOSAR provides description formats for the system as well as for the resources and the configuration of the ECUs. Mapping on ECUs AUTOSAR defines the methodology and tool support to build a concrete system of ECUs. This includes the configuration and generation of the Runtime Environment (RTE) and the Basic Software (RTOS) on each ECU. From the viewpoint of the AUTOSAR Software Component, the RTE implements the VFB functionality on a specific ECU.

18 18 [Pratiksha Dilip Deshmukh] Figure 18: Virtual Function Bus at Application Level At the application level, components are directly connected and interact via Virtual Function Bus (VFB). The VFB represents the component middleware. The application components are developed using the VFB and to be implemented in application concerns only Runtime Environment The runtime environment provides an actual implementation of communication topology and interaction between components. In simple terms, it provides an actual representation of the virtual concepts of the VFB for one particular ECU. Each ECU has its own RTE implementation which is generated during the ECU Configuration process with ECU mapping as input. The mapping of the real interaction implementation takes place depending upon the former Virtual interaction on the basis of location of the component. The communication mechanisms vary on the basis of mapping of the component on ECU. Components mapped to same ECU can be communicated through Intra-ECU mechanisms while others are communicated through Inter-ECU communication. Hence RTE serve as the static implementation of the specialized communication typologies. Figure 19 describes an example of transformation where the components that were virtually connected via one single virtual machine are mapped to more than one ECUs. Due to this mapping on different ECUs, communication between respective components is implemented via a local or remote connection with RTE Comparison between VFB and RTE : Although the concept of Virtual Function Bus and Runtime Environment (RTE) has some fundamental differences but they share a common application programming interface. The application modeler defines the interaction between the software components and VFB while the programming interface is used by the RTE to provide the runtime environment for the application.

19 [Inter-Processor Communication Techniques Evaluation and Comparison] 19 Figure 19: VFB to RTE mapping Component Deployment : Another dimension is the outcome of how the connected components are deployed relative to each other. Two components can be deployed within the same address space, on the same ECU but different address space and on different ECUs. 4 Comparison between Inter-Processor Communication Techniques Interface Wrapper uses the dataflow MoC. In this MoC, the computational steps or firings are initiated due to arrival of data at the input edge. The vertices take the data from the input edge and produce data on the output edge. The production of data on the output edge acts as a trigger for the next firing. Firing rule is totally associated with the firing function. The firing causes the change of internal state. Whereas Ptolemy II follows the mixture of data-driven and demand driven MoC. Among different methods of communication synthesis used in Ptolemy II, the one discussed i.e. Push-Pull model that uses Push-Pull communication between software components. Here the transfer of the data is initiated by Producer or Consumer by sending Push and Pull message requests respectively. The virtual Function Bus follows the time-based MoC [10] as it supports the Active and Passive Communication Primitives and the interaction between the software components causes a variety of timing dependencies. The passive communication primitive are executed within the thread of execution of the client that are request the service while Active Communication Primitives are those that own at least one thread of execution, thus have to provide at least one interface for activation by the infrastructure services. Ptolemy II is a concept for modeling and simulation and uses mixture of MoC. While interface wrapper is meant for modeling, synthesis and simulation and remain confined to the dataflow MoC. In the communication synthesis phase, Interface wrapper uses the concept of communication between different processing elements with the help of buffers. Ptolemy II uses the component interaction

20 20 [Pratiksha Dilip Deshmukh] models e.g. Push-Pull model for the communication is one of the MoCs while AUTOSAR uses the VFB as logical encapsulation over RTE and software components. In case of Interface wrapper and Ptolemy II, communication synthesis a part of the design flow as this concept are modeled using model-based design. While AUTOSAR architecture is not originally modeled by model-based design. Ptolemy II has advantages over Interface Wrapper. It supports mixture of MoC, while Interfacewrapper can be modeled only on Data-driven model of computation. On the other hand, VFB is meant only for AUTOSAR architecture, while Interface Wrapper is meant for hardware-software synthesis over heterogeneous platform. 5 Conclusion This paper shows that the model-based design provides an efficient approach to establishing a common framework for communication throughout the design process supporting the development cycle. It reduces the complexity of structure and software code. Over different stages of the communication like dataflow behavior, partition, etc. The System and communication refinement in Inter-processor communication techniques gives the insight of communication between different processing elements. This communication follows different MoC. The original system can be mapped and compared with each other with respect to model-based design flows /tools to increase the level of abstraction and to reduce the complexity of the implementation on the original hardware platform. The Inter-processor or Inter-Component communication in any architecture can be studied at abstract level with the help of model-based design. References [1] Autosar. [2] Field-Programmable Gate Array. array. [3] Model-based design. [4] ORCC. [5] Virtual Function Bus in Autosar. virtual-functional-bus/. [6] Christian Bradatsch, Florian Kluge & Theo Ungerer (2014): Comparison of Service Call Implementations in an AUTOSAR Multi-core OS. Type (of report) 21, Institution, Address, doi: /eptcs. Available at Note. [7] Christopher Brooks, Edward A. Lee & Stavros Tripakis (2010): Exploring Models of Computation with Ptolemy II. Organization. [8] Jack B. Dennis (1974): First version of a data flow procedure language, pp Springer Berlin Heidelberg, doi: / Available at [9] J. Eker & J. Janneck (2003): CAL Language Report. Organization. [10] Kay Klobedanz, Christoph Kuznik, Andreas Thuy & Wolfgang Mueller (2010): Timing Modeling and Analysis for AUTOSAR-based Software Development: A Case Study. In: Proceedings of the Conference on Design, Automation and Test in Europe, DATE 10, European Design and Automation Association, 3001 Leu-

21 [Inter-Processor Communication Techniques Evaluation and Comparison] 21 ven, Belgium, Belgium, pp Available at [11] Edward A Lee (2008): Cyber physical systems: Design challenges. In: th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), IEEE, pp [12] G. De Micheli (1999): Hardware synthesis from C/C++ models. doi: /date [13] Naveen Mohan & Hannes Zgner (2012): Connecting AUTOSAR VFB to Simulink Environment. Master s thesis. Available at [14] Claudius Ptolemaeus: System Design, Modeling, and Simulation using Ptolemy II, Ptolemy.org, 2014 edition. Available at [15] Ghislain Roquier, Endri Bezati & Marco Mattavelli (2012): Hardware and Software Synthesis of Heterogeneous Systems from Dataflow Programs 2012(21): doi: /2012/ Available at [16] Richard Thavot, Romuald Mosqueron, Julien Dubois & Marco Mattavelli: Hardware synthesis of complex standard interfaces using CAL dataflow descriptions. Available at HardwareSynthesisofComplexStandardInterfacesUsingCALDataflowDescriptions.pdf.