Harritsø, Kevin

Nielsen, Jimmy Jessen

Revsbech, Kasper

Steffen, Rainer

    Aalborg UniversitetAnalysis of IP-based Real-Time In-Car Networks with Network CalculusRevsbech, Kasper; Nielsen, Jimmy Jessen; Harritsø, Kevin; Steffen, RainerPublication date:2009Document VersionPublisher's PDF, also known as Version of recordLink to publication from Aalborg UniversityCitation for published version (APA):Revsbech, K., Nielsen, J. J., Harritsø, K., & Steffen, R. (2009). Analysis of IP-based Real-Time In-Car Networkswith Network Calculus. Paper presented at RTSS 2008 - The 29th IEEE Real-Time Systems Symposium,Barcelona, Spain.General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.            ? Users may download and print one copy of any publication from the public portal for the purpose of private study or research.            ? You may not further distribute the material or use it for any profit-making activity or commercial gain            ? You may freely distribute the URL identifying the publication in the public portal ?Take down policyIf you believe that this document breaches copyright please contact us at vbn@aub.aau.dk providing details, and we will remove access tothe work immediately and investigate your claim.Downloaded from vbn.aau.dk on: May 01, 2017Analysis of IP-based Real-Time In-Car Networkswith Network CalculusKasper Revsbech, Kevin Harritsø, Jimmy Jessen NielsenElectronic SystemsAalborg University, DenmarkEmail: {revsbech,khar04,jjn}@es.aau.dkRainer SteffenBMW Group Research and TechnologyMunich, GermanyEmail: rainer.steffen@bmw.deAbstract—This work investigates the possibility of using Deter-ministic Network Calculus to verify real-time constraints in IPbased in-car networks. A combination of the Real-Time Calculustoolbox [?] and the Cyclic Network Calculus toolbox [?] has beenused to create a model of a switch providing fixed priority/FIFOscheduling. Considerations on how to model such a switch ingeneral and how to create a model in the toolbox are presented.The switch model is validated by inspection and soundness checkof results for varying model parameters.I. INTRODUCTIONAutomobiles are nowadays designed with an increasingamount of Electronic Control Units (ECUs) to provide higherfunctionality in regards to safety, performance, entertainmentand comfort. These ECUs receive sensory input, process it andtransmit control output to other ECUs, actuators, transducersetc. placed at various positions in the automobile. Therefore,an in-car network is deployed to interconnect these compo-nents and functions. Typically, an in-car network is based on anumber of different fieldbuses/networks, such as CAN, MOST,LIN and FlexRay.Recently an interest of unification of network technologyhas emerged. The BMW Group has been investigating the fea-sibility of creating an IP based in-car network using prioritizedEthernet, 802.1P for media access control and the IP protocolfor routing and delivery of data packets between nodes in thenetwork [?]. As concluded in [?], it is possible to create such anetwork and a proof of concept implementation has been con-ducted to support this conclusion. To investigate the feasibilityand verify that the technology of IP and Ethernet can be usedin such time critical applications, an analysis of the real-timeperformance has to be conducted. One way of doing so is byuse of Deterministic Network Calculus (DNC) constituting atheoretical (non) deterministic basis for determining worst casebounds on bandwidth usage, delay and buffering requirementsthroughout a network and thereby applicable for verifying thereal-time performance of networked systems. DNC was firstintroduced in [?] and later extensively described in [?].This work investigates the possibilities of using the theoryof DNC and DNC based tools in the design and verificationprocess of an in-car network. Here we presents the first stepof this investigation process; namely the construction of anetwork model of an in-car network. First a study of an in-car network is described in Sec. II where the topology andcomponents on the network model are identified. In Sec. IIIthe theory of DNC is briefly presented, along with an introduc-tion to the DNC based MATLAB R© toolbox Cyclic NetworkCalculus (CyNC), which uses the Real-Time Calculus (RTC)Toolbox as a framework for doing DNC calculations. SinceEthernet/IP routers are the key scheduling elements in aunified in-car networks, their models become essential for thedesign process. The modelling of a fixed priority/FIFO switchis presented in Sec. IV along with various possibilities forrepresenting the models in DNC/CyNC. In Sec. V a validationof the switch model is conducted by combining the switchmodel with a model of data in an in-car network and inspectinghealthiness of results. This is done by inspecting the impact ofprioritization and by varying the delay for a particular elementand inspect the impact on the maximum delays. A comparisonwith real recorded data is not reported in this work, but plannedas an activity for the near future. Finally a conclusion ofthe presented work is given and the future perspectives arepresented.II. IN-CAR NETWORK DESCRIPTIONTo create a DNC model of an in-car network, one has to beable to describe the network topology and the componentswithin the network. Here we present a possible networkstructure of an in-car network. There are at least six differenttraffic domains on the in-car network, which can be classifiedas follows: Chassis, Comfort, Driver assistance, Entertainment,Infotainment and Power train. Each of these domains consistsof multiple nodes in which numerous connections of differentpriority are created. The traffic is then sent through a numberof switches before reaching the destination.However, instead of creating one large model of the net-work, the internals of each domain can be modelled separatelyas long as the traffic pattern leaving a domain remains thesame, internal changes do not affect the other domains. Thismeans that a topology as in Fig. 1 can be used where a centralunit switch connects all the sub domains that can be modelledindividually. However to do so, a model of the central unitswitch has to be created. As described in [?] a solution toensure the real-time demands of critical traffic is to use fixedprioritization, which means that the central unit switch isconsidered as a prioritized switch. It has been chosen to assignthe priorities as listed in Table I to the flows traversing theFig. 1. The topology of an in-car network where a central unit switch isused to allow intercommunication between the six traffic domainscentral unit switch. These priorities are chosen as realisticpriorities but only serve the purpose of allowing test of themodel and have to be reconsidered.TABLE IPRIORITIES OF THE TRAFFIC FLOWS TRAVERSING THE CENTRAL UNITSWITCH. INTRA DOMAIN TRAFFIC IS NOT CONSIDERED IN THE DEFINITIONOF THE PRIORITIES, AND IS THEREBY LEFT BLANK IN THE TABLE.Priority SourceDestination Chas. Comf. D. A. Info. Mult. P. T.Chassis 3 2 6 7 1Comfort 3 5 6 7 4Driver A. 2 5 6 7 2Infotainment 6 6 6 6 5Multimedia 7 7 7 7 5Power T. 1 4 5 6 7III. DETERMINISTIC NETWORK CALCULUSMETHOD AND TOOLSIn network calculus all traffic and service in the describednetwork is expressed non-deterministically in terms of timedependent bounds. The traffic is expressed by upper and lowerarrival bounds and the processing/communication-services byupper and lower service bounds. Arrival and service boundsare given in terms of time functions/curves bounding ar-rival/service above and below for a time interval of specifiedduration. In this work we confine ourselves to affine andstaircase functions to represent arrival/service bounds. Eq. (1)presents an affine arrival curve where r denotes maximumlong term arrival rate of the flow and b denotes the maximumtransient burst of the flow. The function to express a periodicarrival curve can be seen in Eq. (2) where T denotes theinterval between arrivals for the flow and τ the maximumdelay jitter of periodic arrivals [?].γr,b(t) = rt+ b ∀ t ≥ 0 (1)vT,τ (t) = d t+ τTe ∀ t ≥ 0 (2)βr,T = r[t− T ]+ ∀ t ≥ 0 (3)To express the service of a serving unit a so called rate latencyfunction in Eq. (3) is used where r denotes the minimum longterm service rate provided by the serving element and T themaximum latency time. As shown in Fig. 2 bounds based onFig. 2. The inputs and outputs for a service element. As shown the serviceelement provides bounds on the outbound flow α∗ and the outbound resourceβ∗ which is the service left after serving flow α.the inbound flow and resources can be calculated per serviceelement. Using the theory of [?] the outbound flow α∗ canbe found as α∗ = α  β where α denotes the arrival curvethat constrains the inbound flow and β denotes the servicecurve that constrains the inbound resources. To calculate theworst case queue length Q at the service element the maximalvertical distance between the arrival curve and the servicecurve is found as expressed in Eq. (4). The maximum delayD imposed by the service element is the maximal horizontaldistance between the arrival and service curve and is found asexpressed in Eq. (5) [?].Q ≤ supt≥0{α(t)− β(t)} (4)D ≤ supt≥0{inf{τ | α(t) ≤ β(t+ τ)}} (5)The theory of DNC is applied to the in-car network modelwith a combination of the CyNC toolbox [?] and the RTCtoolbox [?] merged into one common toolbox using the calcu-lation engine for e.g sup-minus convolution and expression offlows as curves from RTC combined with the graphical userinterface, the ability to handle cyclic flows and the schedulingelement algorithms from CyNC. This combination enablesa graphical modeling tool where graphical blocks are usedto express the arrival bounds and scheduling elements aswell as connections between blocks to represent the routingin the network. Furthermore the properties of each elementhave to be specified. E.g. for a service/processing elementthe appropriate scheduling algorithm is specified along withservice rate and preemption delay.When a model has been created and the calculation enginehas converged, the tool provides stability guarantees for thesystem, i.e. that every queue has an upper limit below ∞.Furthermore the tool calculates maximum queue length of aservice element and the maximum delay that a traffic flow canexperience for each service element. This enables a the userto calculate the total delay a flow can experience throughoutthe system. First the total service provided to the flow aftertraversing each service element is calculated by a convolutionof each service provided, then Eq. (5) is used where β is thetotal service and α the arrival bound of the flow. By providinga stability guarantee, a guarantee of max delay and queuelength the tool can be used to analyse the feasibility of aFig. 3. A switch consisting of three types of service elements. Input ports,a back plane and output ports.particular network consisting of a number of service elementsand traffic flows.IV. SWITCH MODELINGThe first step of investigating DNC for an in-car network isto create a general model of the central unit switch shown inFig. 1. In this section we will show the principles of how amodel of a prioritized switch can be constructed but withoutconsidering specific switch brand dependent details. In generalat least three types of service elements exist within a switch:input ports, a back plane and output ports see Fig. 3. Notethat the switch is modelled as full duplex meaning that everyport has an input and an output queue that is independentbut shares the same back plane. Each element can then beexpressed by the appropriate scheduling method e.g. First InFirst Out (FIFO). As described in Sec. II a prioritizing setupwith fixed priorities is considered. The CyNC toolbox providesa fixed priority block as default where a total service of theelement is given as input and every flow is connected inits respective priority. However in the considered use-case,equally prioritized flows with potentially different source anddestination exist. Therefore these flows cannot be aggregatedand fed to the same input. We propose to solve this by utilizingthe fact that a service element outputs the remaining serviceβ∗ after serving the arrival flows, show in Fig. 2. By usinga FIFO scheduling element for flows of same priority andletting the top priority FIFO ”use” the needed resources andpassing the remaining resources to the second priority FIFOa fixed priority scheduler service element capable of handlingmultiple flows of same priorities can be modelled in CyNCsee an example in Fig. 4.Designing a fixed priority switch one has to ensure that thepriority is kept throughout the whole switch, implementingonly the back plane as prioritized is not sufficient. The outputports must also have a queue for each priority. Of coursethe model also have to afflict the design which leads intoa more complex model of the switch but also more precise,where the high priority flows do not have to suffer from thelower prioritized flows. Naturally one has to ensure that theswitch in question actually is implemented in that way. A fullyprioritized switch model can be seen in Fig. 5. By using thisparadigm a switch providing fixed priority scheduling amongthe flows and FIFO for flows of same priority can be modelled.Fig. 4. A model of a Fixed priority scheduler with multiple flows of samepriority in CyNCFig. 5. A switch providing fixed priority scheduling where every in and outport has a queue for every priority, the back plane also have a queue for everypriorityUsing the concept shown in Fig. 4 one can build the model inCyNC.V. SWITCH MODEL VALIDATIONTo validate the developed model of a fixed priority switchdescribed in Section IV and to investigate the consequencesof applying realistic data to the fixed priority central switchshown in Fig. 1, a CyNC model has been constructed basedon the paradigm shown in Fig. 5. As shown in Fig. 1 thereare six traffic domains each generating and receiving traffic.Therefore the CyNC model comprises six input and outputports. The properties of each scheduling element do notconform to any particular off-the-shelf switch, but are chosenwithin realistic values. It is chosen to set the minimum serviceTABLE IIMAXIMUM DELAYS FOR THE FLOWS OF DIFFERENT PRIORITIES LEAVINGTHE CHASSIS DOMAIN. CALCULATED FOR TWO SETTINGS OF THE BACKPLANE ONE WHERE THE MAXIMUM DELAY OF SERVICE IS 0.053 MS ANDONE WITH 1.053 MS MAXIMUM DELAYFlow Priority Delay 0.053 ms Delay 1.053 mschassis→pTrain 1 0.1695 ms 1.169 mschassis→driverAssist 2 0.3024 ms 1.303 mschassis→comfort 3 0.3771 ms 1.378 msof the scheduling elements as follows: Input and output ports:100 Mbit/Sec with no delay, back plane: 304 Mbit/Sec andmax delay of 0.053 millisecond.To validate the prioritization model prioritized traffic hasto be applied. In this case it is chosen to apply the trafficspecifications of an existing BMW configuration to ensurerealistic arrival data1. This data arrives from the six domainsshown in Fig. 1. The original flow data are derived from arepository of individual flows each represented by individualstaircase arrival curves (Expressed by Eq. (2)) which givea very complex model in terms of creating an entity forevery flow. To reduce the complexity flows sharing source,destination, receiver and priority have been aggregated. How-ever this yields a complex arrival curve description and inturn computational complexity. To reduce the arrival curvecomplexity the aggregated arrival curve has been transformedinto an affine arrival curve. The price of doing so is a slightoverestimation of the arriving traffic which leads into anoverestimate of the needed resources.Using the presented switch model with the described dataflows the maximum delays listed in Table II were obtained.As seen in the table the maximum delays for the flows leavingthe Chassis are increasing as the priority gets lower. This isan immediate consequence of the fact that the lower priorityflows have less resources. If the delay is increased in the backplane from 0.053 ms to 1.053 ms while keeping other settingsfixed, the maximum delay becomes as listed in Table II. Asseen in the table the total delays are only affected by the extradelay added to the back plane and as shown all the flows areaffected by the reduced overall service service in the backplane.VI. CONCLUSION AND OUTLOOKThe theory of DNC has been used to develop a fixed priorityswitch paradigm, which has been implemented in the matlabtoolbox CyNC. Utilizing the knowledge of an in-car network,the developed switch paradigm and CyNC implementationhave been used to model a fixed priority switch. The fixedpriority switch model uses a chain of FIFO blocks to allowmultiple equally prioritized input flows that cannot be ag-gregated. Test results have shown that the maximum delaysincrease for a flow as the priority is lowered.1Note that even thought the input data is authentic the results do not showanything about the present and future cars networks as the properties of thescheduling elements only are realistic but not derived from equipment usedin carsThe proposed modeling framework based on CyNC andDNC allows for direct specification of switch properties andinbound data flows, while the maximum delays can be readdirectly from the model. With the implementation of the fixedpriority switch model, the first step towards an analyticalverification and design method for IP based real-time in-carnetworks as proposed in [?] has been taken.A next step could be to provide automated model dataacquisition, i.e. for network components and traffic charac-teristics as well as preparation of model data for use in aDNC framework. Regarding the switch, the first job is toquantify its precise properties in the time domain. Modeldata may be extracted from data sheets, which however isoften quite laborious and not feasible for automation. As analternative, empirical methods based on system identificationmay be applied. Parameters for models in a repository ofassumed internal structure model parameters may be foundfrom observations of ingress and egress flows. Furthermore,the calculated delays and queue lengths of an existing systemshould be compared to the measured delays and queue lengthsin an existing in-car network to estimate the overestimationimposed by a DNC based analysis.ACKNOWLEDGMENTThe authors would like to thank BMW Group for thecooperation and supervision. We would also like to thankJohan de Claville Christiansen, Kristian Engh Lundgreen andYoussef El Otmani for the research effort behind this paper.The research work was in parts conducted in the context ofa student project at the Department of Electronic Systems atAalborg University, and as such supported by the Study Boardat Aalborg University, see www.esn.aau.dk.

Analysis of IP-based Real-Time In-Car Networks with Network Calculus

http://vbn.aau.dk/files/19087124/paper.pdf

Analysis of IP-based Real-Time In-Car Networks with Network Calculus

Abstract

Similar works

Full text

Available Versions

VBN