CAN总线系统的实时对象调用毕业论文外文文献翻译及原文

　　毕 业 设 计（论文）

　　外 文 文 献 翻 译

　　文献、资料中文题目： CAN总线系统的实时对象调用

　　文献、资料英文题目：Invocation of Real-Time Objects in a CAN Bus-System

　　文献、资料来源：

　　文献、资料发表（出版）日期：

　　院 （部）：

　　专 业：

　　班 级：

　　姓 名：

　　学 号：

　　指导教师：

　　翻译日期： 2017.02.14

　　Invocation of Real-Time Objects in a CAN Bus-System

　　Abstract

　　The paper focuses on method invocation of real-time objects in a CAN-based distributed real-time system. A simple object model is introduced, which allows the convenient modelling of hardware and software components. Related to the object model, two issues are discussed. Firstly, a model is introduced which allows to form and address object groups. This reflects a basic need in a real-time system to distribute information to multiple clients efficiently. Secondly, we discuss an approach to express timing requirements for object invocations. To achieve distributed consensus on communication resource access, an EDF-like approach is introduced, which takes advantage of knowledge about deadlines, the number of remaining communication activities, and the remaining worst-case execution time for the invoked method at each point of time.

　　1. Introduction

　　Future computer systems will, to a large extent, monitor and control real-world processes. This results in an inevitable demand for timeliness and reliability. Distributed systems which inherently provide immunity against single failures are an adequate architecture to meet the goal of reliability. Additionally, because realworld applications often require the spatially distributed control of electromechanical components, a distributed system architecture brings computing power to the points where it is needed. The availability of inexpensive yet powerful microcontrollers supports a distributed solution. This results in a system model which is composed from smart components implementing the instrumentation interface to the real world comprising sensors and actuators. A convenient way to model such an environment is to use an object-based approach where objects encapsulate all kinds of entities necessary to control a physical process.

　　We can identify at least two layers in systems interacting with the real world. A lower responsive system level tightly controlling the sensor/actuator interface to the world and a higher system level responsible for interpretation and evaluation of the perception of the world as communicated by the instrumentation interface. In this layer, higher level decisions are performed. Although these different levels have different requirements concerning responsiveness, they are sometimes not separated clearly simply because of the hardware architecture. We concentrate on the lower system level and describe an object model which is

　　motivated by a system structure which relies on a modular design and independent computing resources for the components of the instrumentation interface. Rather than having a central powerful processor in which electromechanical components are only modelled as objects from which control signals are generated, the electromechanical components are objects themselves powered by inexpensive microcontrollers. The objects of this layer have a well defined interface to be easily controlled by a higher level instance which can exploit this abstraction rather than dealing with low level control signals.

　　The hardware modules are connected by a field-bus. We choose the CAN-bus (CAN: Controller Area Network), developed by BOSCH[[28]] because it provides advanced technical features and represents an emerging standard with a wide applicability. Moreover, popular microcontrollers are available with an on-chip CAN controller. CAN is a shared bus designed to connect control systems in a spatially restricted area like cars, robots, tool machines, and other automotive or industrial automation applications. It is targeted to operate in a noisy environment with speeds of up to 1 Mbit/sec, exchanging small real-time control messages. We use the CAN message format to uniformly invoke methods on our objects. This allows a transparent object invocation in the sense that an invoking object must not know where the invoked object resides in the system. Additionally, we can address groups of objects with a single CAN message.

　　As a common resource, the communication medium has to be shared by all computing nodes. Access to the medium has to be scheduled in a way that distributed computations meet their deadlines in spite of competition for the communication line. Since the scheduling of the bus cannot be based on local decisions, a distributed consensus about the bus reservation has to be achieved. Clearly, this is only a special case of the more general problem to schedule a cooperative distributed computation.

　　There exist several alternative approaches to solve this problem based on the assumptions about the behaviour of the system and the environment. The first approach, known as time-triggered approach [[18]],[[21]], [[19]] assumes a complete knowledge of all future actions of the system. Hence, during operation these systems exhibit minimal overhead paired with a maximum of predictability and are highly appropriate for safety-critical applications which can be modelled by a periodic behaviour.

　　A more adaptable and economic way to manage system resources has to be based on run-time information. These real-time systems have to plan their operation at run-time, at least to a certain extent. Although the trade-off generally is between adaptability and predictability, these systems are scalable in the sense that they allow a coexistence of activities with different real-time requirements. These systems rely on run-time guarantees [[30]],[[11]] rather than on

　　a preplanned feasibility guarantee only. A form of calendar-based scheduling [[22]],[[30]] is an approach to run-time guarantees where hard real-time activities have the possibility to reserve resources in advance. The free resources can be used by less important tasks. It should be noted that scheduling policies like e.g. earliest deadline first (EDF), least laxity first (LLF) or rate monotonic scheduling only guarantee optimality, i.e. if a schedule exists, it will be found. But in the dynamic system, there may be conflicting requests for which these scheduling policies will not find a solution. In this case they fail to guarantee anything. A calendar, on the other hand, is a mechanism to guarantee resource availability for reservations which have already been made.

　　2. The System Model

　　Our system model is influenced by our anticipated hardware basis. We assume a number of different microcontrollers with different performance attributes ranging from 8Bit to 32Bit architectures. All microcontrollers are equipped with a CAN-Bus interface. We exploit the different performance and price characteristics of the microcontrollers to structure the overall task of the system into small packages. Since the simple microcontrollers are in the range of a few $s,it must no longer be a rare resource. In our application example, a simple active suspension system (Fig. 2-1),we use a simple microcontroller for each servo or complex sensor. A servo is composed from a motor and an internal sensor which provides feedback on the current position. This sensor/actuator system is connected to the CAN-bus to cooperate with other similar objects and receive control commands through CAN messages. No direct, low level control signals are visible outside the module. Thus, encapsulation and a well defined interface are supported. On the logical level, the sensor/actuator block is seen as an object on which certain methods can be invoked, e.g. to position itself to a specific angel, to communicate the angel, etc.A sensor/actuator constitutes the lowest level in the control hierarchy, comparable with a simple reflex loop in a biological system. Higher control instances are available to control groups of objects or eventually the entire system using more powerful microprocessors. Thus, the higher control instances have a well defined instrumentation interface which is composed from objects, each encapsulating a certain functionality.

　　An object has a unique name and a set of associated operations. The unique name of the object is translated to a short form system name during run-time and maintained by a configuration service. Objects in such an environment must have some extensions to the sequential, passive model known from the field of programming languages. Particularly our model includes:

　　1). Active, autonomous objects.

　　Since objects may have a dedicated processor, it is straightforward to assume a model of autonomous, active objects. An object is characterized by a name and a list of methods which can be invoked on the object. Because the object is active, it can also export information. This is equivalent to sending an invocation to another object or to a group of objects without a previous request. As described in chapter 3, we provide a transparent group communication mechanism, i.e. an object itself usually does not know whether it communicates with an object on a remote or on the local node. This group communication mechanism is a basis for remote method invocation of object groups. In fact, communication relations can dynamically be defined during run time. So, objects may join or leave a group, and are autonomous in deciding when to process a request.

　　The concept of TMO (time-triggered message triggered object) [[16]] derived from the RTO.K (Real- Time Object) [[17]] concept enhances the conventional object model by mechanisms to specify the temporal behaviour of an object. It provides a framework to specify a complex real-time system together with its environment in the same uniform representation. The aim is an integrated design of a distributed real-time system and simulators generating real-time input modelling the target applications. A TMO exhibits active, spontaneous behaviour as well as providing services requested by a method call. Three execution models are derived for executing TMOS [[17]].Among them, the execution model which provides a dedicated processor for each object (Type II) is very similar to our basic system structure. The difference on the conceptual level is the notion of the object group and the fact that we do not relate spontaneous behaviour to clock events. However, if the spontaneous activity of an object is hard real-time, we also have to map it to some reserved time slot.

　　CHAOS [[11]] demonstrates that the object model can be tailored to meet the efficiency requirements of realtime applications. The motivation also comes from a robotics application where electromechanical components are encapsulated and controlled by objects. CHAOS provides a spectrum of objects with different weight ranging from light weight passive objects to objects including several processes providing scheduling and synchronization facilities. The concept is targeted to rather powerful parallel machines. The active objects are too heavy weight to implement them with our simple hardware basis.

　　In Alpha,[[12]],objects are passive abstract data types in which a number of processes can execute concurrently. MARUTI [[22]] provides modules in the design process. However, these modules are broken down into elementary units (EUS) which constitute the atomic entities of sequential execution. Also, EUS resemble to objects, they are not user defined but

　　derived during the compilation process [[25]].

　　2). Object groups.

　　In conventional object-oriented languages a method invocation is synchronous and directed to a single object. It is usually not possible to express a request to a group of objects. However, in a real-time control system it is beneficial to provide groups of objects and to use asynchronous multicasts to invoke methods of these groups. The motivation ranges from simple and fast distribution of information, like sensor data and alarm messages, to replicated objects forming a group to achieve fault-tolerance. Because the communication medium, the CAN-Bus, supports consistent multicasts on the low system level, it is beneficial to exploit this feature. It allows to address a group of N objects with one message rather than sending N individual messages. To a certain extent, CAN provides atomicity of message transfer, i.e. either all operational nodes correctly receive a message or none of them.

　　The consistent view of the message status between all nodes is one of the most important features of the CAN bus (cf. chapter 3).It is achieved on the hardware level by a synchronous bit transmission approach. All receivers of a CAN message (including the sender) scan the bus and analyze the current message status during the transmission of every transmitted bit. If a node locally detects a transmission failure, it immediately invalidates the current message by intentionally producing an detectable error on the bus. Every node including the sending node now is aware that the message transfer failed. Automatically, the sender will eventually retransmit the message. If no transmission error is detetcted, all operational nodes have received and accepted the message. A more detailed description of this feature and its exploitation for atomic group communication is given in [[14]][[28]].

　　The basic inter-object communication in systems like JAVA and CORBA focus on a point-to-point communication., there are some one-to-many communication methods in JAVA like the observable/observer class [[1]] or recently, the iBus [[24]].Both mechanisms are based on a explicit registration of clients at the server which differs significantly from a general group communication mechanism which is a many-to-many communication paradigm.

　　The transparent communication mechanism used e.g. in MARUTI [[25]] enables the objects to use a send primitive without specifying the receiver(s).This is done by specifying the communication channel bindings in the MARUTI configuration language (MCL).The goal is to separate functional and non-functional issues. However, the binding is performed during compile time. No dynamic changes of the communication relations are possible.

　　The communication model which we adopt is similar to that of autonomous decentralized systems (ADS) [[26]].In this model, software subsystems autonomously manage themselves