OSEK/vdx group, two are of particul

OSEK/vdx group, two are of particular interest for X-by-Wire: OSEKTime operating and fault tolerant communication layer.
9.3.3.1 OSEKTime
OSEKTime OS (OSEK/VDX time-triggered operating systems) [16] is small operating system designed to offer the basic services needed by time – triggered applications. In particular, OSEKTime Os offers services for task management, interrup processing, and error handling.
An offline-gennerated dispatcher table, termed a dispatcher round, activates the task in a determinded order and repeats itself as long as the system is running. Several different dispatcher tables, corresponding, for instance, to different functioning modes of the system, can be defined, but the switching from one table to the next an only take place at the end of a round.
Tasks cannot be blocked waiting for an external event, but they can be preempted; a running task will always be preempted by a task that is activated, and the designer must take resource contention into account in this case. An interesting feature of OESKTime OS is the deadline monitoring that can be performend error handling rountine is invoked and the operating system is reinitialized. In OSEKTime OS, the rate at which interrupts can occur is bounded, at a rate specified when the system is configured, in order to keep the system predictable.
As for communication cycles in time- triggered networks, the configuration of the dispatcher round can be done offline theough a software tool that will ensure the correctness of system.
29.3.3.2 FTCom
OSEK/VDX FTCom (fault-tolerant communcation) [17] is a proposal for a software layer that provides services for facilitating the development of fault- tolerant applications on top of time-triggered networks. One important function of FTCom, with respect to X-by-Wire, is to manage the redundancy of data needed for achieving fault tolerance (see Section 29.3.1.2). From an implementation point of view, it is sometimes preferable to present only one copy one copy of data to the application in order to simplify the application code and to keep it independent from the level of redundancy (i.e., the number of nodes composing an FTU). In OSEK/VDX terminology, the algorithm responsible for the choice of the strategies are possible: pick-any (fail-silent node), average value, pick-a-particular-one,majority vote,etc. OSEKFTCom provides a generic way for specifying the agreement strategy of replicated data.
Two other important services of thr FTCom are (1) management of the packing and unpacking of messages [18], which is needed if the use of network bandwidth has to be optimized, and (2) provision of message-filtering mechanisms for passing only significant data to the application.
29.1 Steer-by-Wire Architecture: A case Study
A Steer-by-Wire system aims to procide two main services: controlling the wheel direction according to the driver’s request and providing a mechanical –like force feedblack to the handweel. In this section, we present the functional point of view of such a system, the real-time and dependablity properties that have to be observed, and a realistic operational Steer-by-Wire system used as a reference architecture for evaluation purposes. Finaally, we will focus on the real-time requirements, and after proposing a way to model failures, we will show how each comonet or subsystem of the reference architecture can reach the dependability objective.
29.4.1 Functional Description of a Steer-by-Wire System
In a Steer-by-Wire system, two main services have to be provideed: the front-axle actuation and the handwheel force feedback. So, from a functional point of view, this implies two main funtions that are
Buit upon the standard CAN protocol, but the controllers must be able to disable automatic retrans-mission and provide the applicatino with the time at which the first bit of a frame was sent r received [15]. The bus togology of the network, the charateristisc of the transmission supporl, the frame format, as well as the maximum data rate ( 1Mbits/s) are imposed by CAN protocol. Channel redundancy is possible, but not standardized, and no bus guardian is implement in the node. A illustrated in Figure 29.3, TCAN defines a basic cycles ( the equivalent of the FlexRay communication cycle) as the concatenation of one or several time-triggered (or exclusive) windows and one event-triggered (or arbitrating) window. Exclusive window are devoted to time-triggered transmissions (i.e., periodic messages), while the arbitrating window is ruled by the standard CAN protocol: transmissions are dynamic and bus access is granted according to the priority of the frames. Several basic cycles that differ by their organization is exclusive and arbitrating windows and by the messages sent inside exclusive windows can be defined. The list of successive basic cycles is called the system matrix and is executed in loops. Interestingly, the protocol enables the master node, the node that initiates the basic cycle through the transmission of the reference message, to stop the functioning in TTCAN mode by sending a refference message.
TTCAN is built on a well-mastered and cheap technology that is CAN but, as defined by standard, does not provide important dependability services such as the bus guardian, membership serve, and reliable acknowledgment. It is, of course, possible to implement some of these mechanisms at the application or middleware level, but with a reduced efficiency. It seems that carmarker may consider the use of TTCAN for some systems during a transition period until the FlexRay technology is fully mature.
29.3.3 Operating Systems and Middeware Services
In the context of automotive applications, middeware is a software layer located above the platform (hardware, operating system, protocols) that aims to offer high-level services to the application in order to reduce the time needed to market and improve the overall quality of system. The main purpose of middleware is to hide the distribution of the middeware is to provide high-level services, and for X-by-Wire applications, services related to dependability are needed.
Several projects aimed at the development of automotive middleware layers have been undertaken ( EAST, www.east-eea.net; AUTOSAR, http://www.autosar.org/). To the best of our knowledge, the only results publicly have been produced in the context of the OSEK/VDX consortium ( detailed information can be obtained at http://www.osek-vdx.org), which is a project of the automotive industry whose objective is to buid a standard architecture for in –wehicle control units. Among the results of the



Creates the software model for each function or subfunction. The resulting list of processes is scheduled for ECU, taking into account local constraints as well as the global constraints defined in the communication schedule.
Note that for performing the local design, the supplier solely requires parts of the global information created by the OEM as well as his own knowledge on the ECU. In principle, the suppliers do not influence each other.

Kết quả (Việt) 1:

Nhóm OSEK/vdx, hai quan tâm đặc biệt cho X bởi dây: OSEKTime hoạt động và lỗi khoan dung truyền thông lớp.9.3.3.1 OSEKTimeHệ điều hành OSEKTime (OSEK/VDX thời gian-kích hoạt hệ điều hành) [16] là nhỏ hệ điều hành được thiết kế để cung cấp các dịch vụ cơ bản cần thiết của thời gian-kích hoạt các ứng dụng. Đặc biệt, Hệ điều hành OSEKTime cung cấp các dịch vụ quản lý công việc, interrup xử lý và quản lý lỗi.Một diễn đàn gennerated dispatcher bảng, gọi là một dispatcher tròn, kích hoạt nhiệm vụ theo một thứ tự determinded và lặp đi lặp lại chính nó khi hệ thống đang chạy. Một số bảng khác nhau dispatcher, tương ứng, ví dụ, để chế độ hoạt động khác nhau của hệ thống, có thể được định nghĩa, nhưng các chuyển đổi từ một bảng để tiếp theo một chỉ diễn ra ở phần cuối của một vòng.Tác vụ không thể bị chặn chờ đợi cho một sự kiện bên ngoài, nhưng họ có thể được preempted; một nhiệm vụ chạy sẽ luôn luôn được preempted bởi một nhiệm vụ được kích hoạt, và các nhà thiết kế phải mất tài nguyên ganh đua vào tài khoản trong trường hợp này. Một tính năng thú vị của hệ điều hành OESKTime là thời hạn giám sát mà có thể là performend lỗi xử lý rountine được gọi và hệ điều hành reinitialized. Trong hệ điều hành OSEKTime, tỷ lệ mà tại đó ngắt có thể xảy ra được bao bọc ở mức quy định khi hệ thống được cấu hình, để giữ cho hệ thống dự đoán được.Đối với thông tin liên lạc các chu kỳ trong thời gian-kích hoạt mạng, các cấu hình của dispatcher vòng có thể thực hiện diễn đàn theough một công cụ phần mềm mà sẽ đảm bảo tính đúng đắn của hệ thống.29.3.3.2 FTComOSEK/VDX FTCom (lỗi khoan dung communcation) [17] là một đề nghị cho một lớp phần mềm cung cấp các dịch vụ để tạo điều kiện cho sự phát triển của lỗi - khoan dung ứng dụng trên đầu trang của thời gian-kích hoạt mạng. Một chức năng quan trọng của FTCom, đối với X bởi dây, là để quản lý sự thừa dữ liệu cần thiết để đạt được khả năng chịu lỗi (xem phần 29.3.1.2). Từ một điểm thực hiện của xem, nó là đôi khi thích hợp hơn để hiện nay chỉ có một bản sao một bản sao của dữ liệu để ứng dụng để đơn giản hóa các ứng dụng mã và để giữ độc lập từ mức độ của sự thừa (tức là, số lượng các nút soạn một FTU). Trong thuật ngữ OSEK/VDX, các thuật toán chịu trách nhiệm cho sự lựa chọn của các chiến lược là có thể: chọn bất kỳ (thất bại-im lặng nút), giá trị trung bình, chọn một đặc biệt một, đa số phiếu, vv. OSEKFTCom cung cấp một cách chung để chỉ định chiến lược thỏa thuận của sao chép dữ liệu.Hai dịch vụ quan trọng khác của thr FTCom là (1) quản lý của đóng gói và giải nén của tin nhắn [18], đó là cần thiết nếu sử dụng băng thông mạng lưới đã được tối ưu hóa, và (2) cung cấp cơ chế lọc thông báo cho đi qua chỉ dữ liệu quan trọng để các ứng dụng.29,1 kiến trúc chỉ đạo bởi điện tử: một nghiên cứu trường hợpMột hệ thống chỉ đạo bởi dây nhằm mục đích procide hai dịch vụ chính: kiểm soát bánh xe hướng theo yêu cầu của lái xe và cung cấp một cơ khí-như lực lượng feedblack để handweel. Trong phần này, chúng tôi trình bày những điểm chức năng của xem của một hệ thống như vậy, trong thời gian thực và thuộc tính dependablity phải được quan sát thấy, và một hệ thống chỉ đạo bởi dây hoạt động thực tế được sử dụng như là một kiến trúc tài liệu tham khảo cho mục đích đánh giá. Finaally, chúng tôi sẽ tập trung vào các yêu cầu thời gian thực, và sau khi đề xuất một cách để mô hình thất bại, chúng tôi sẽ hiển thị như thế nào mỗi comonet hoặc hệ thống phụ của kiến trúc tài liệu tham khảo có thể đạt được mục tiêu độ tin cậy.29.4.1 chức năng mô tả của một hệ thống chỉ đạo bởi dâyTrong một hệ thống chỉ đạo bởi dây, hai dịch vụ chính đã là provideed: càng trục trước và handwheel lực lượng thông tin phản hồi. Vì vậy, từ một điểm của xem chức năng, điều này ngụ ý hai thiết chínhBuit sau khi các tiêu chuẩn có thể giao thức, nhưng các bộ điều khiển phải có khả năng để vô hiệu hoá tự động retrans-nhiệm vụ và cung cấp applicatino với thời gian mà tại đó các bit đầu tiên của một khung được gửi r nhận được [15]. Togology xe buýt của mạng, charateristisc truyền supporl, định dạng khung, cũng như tỷ lệ dữ liệu tối đa (1Mbits/s) được áp dụng bởi có thể giao thức. Kênh dự phòng là có thể, nhưng không phải tiêu chuẩn hóa, và không có người giám hộ xe buýt là thực hiện trong các nút. A minh họa trong hình 29,3, TCAN xác định một cơ bản chu kỳ (tương đương với chu kỳ FlexRay thông tin liên lạc) như là nối của một hoặc một số thời gian-kích hoạt (hoặc độc quyền) windows và một cửa sổ kích hoạt sự kiện (hoặc arbitrating). Độc quyền cửa sổ được dành để kích hoạt thời gian truyền (tức là, định kỳ thư), trong khi cửa sổ arbitrating được cai trị bởi các tiêu chuẩn có thể giao thức: truyền là năng động và xe buýt đi được cho phép theo mức ưu tiên của khung. Một số các chu kỳ cơ bản khác nhau của tổ chức của họ là độc quyền và arbitrating cửa sổ và bởi các thư được gửi bên trong windows độc quyền có thể được định nghĩa. Danh sách các chu kỳ cơ bản kế tiếp được gọi là ma trận hệ thống và được thực hiện trong vòng. Điều thú vị, các giao thức cho phép các nút tổng thể, các nút bắt đầu chu kỳ cơ bản thông qua việc truyền tải thông điệp tham khảo, để ngăn chặn các hoạt động trong chế độ TTCAN bằng cách gửi thư ra.TTCAN được xây dựng trên một nắm tốt và giá rẻ công nghệ đó là có thể, nhưng theo định nghĩa của tiêu chuẩn, không cung cấp dịch vụ quan trọng tin cậy chẳng hạn như xe buýt người giám hộ, thành viên phục vụ và sự thừa nhận đáng tin cậy. Đó là, tất nhiên, có thể thực hiện một số các cơ chế tại vào ứng dụng hoặc trung cấp, nhưng với một hiệu quả giảm. Có vẻ như rằng carmarker có thể xem xét việc sử dụng TTCAN cho một số hệ thống trong một giai đoạn chuyển tiếp cho đến khi công nghệ FlexRay là hoàn toàn trưởng thành.29.3.3 điều hành hệ thống và dịch vụ MiddewareTrong bối cảnh các ứng dụng ô tô, middeware là một phần mềm lớp trên nền tảng (phần cứng, Hệ điều hành, giao thức) nhằm mục đích cung cấp các dịch vụ cao cấp ứng dụng để làm giảm thời gian cần thiết để thị trường và cải thiện chất lượng tổng thể của hệ thống. Mục đích chính của middleware là để ẩn phân phối của middeware là để cung cấp dịch vụ cao cấp, và cho các ứng dụng X bởi dây, các dịch vụ liên quan đến độ tin cậy là cần thiết.Một số các dự án nhằm vào sự phát triển của ô tô middleware lớp đã được thực hiện (EAST, www.east-eea.net; AUTOSAR, http://www.autosar.org/). Tốt nhất của kiến thức của chúng tôi, kết quả duy nhất công khai đã được sản xuất trong bối cảnh của các tập đoàn của OSEK/VDX (thông tin chi tiết có thể được lấy tại http://www.osek-vdx.org), mà là một dự án của ngành công nghiệp ô tô, mà mục tiêu là để buid một kiến trúc tiêu chuẩn nhất trong đơn vị kiểm soát-wehicle. Trong số các kết quả của các Tạo ra các mô hình phần mềm cho mỗi chức năng hoặc subfunction. Danh sách kết quả của quá trình được lập biểu cho ECU, tham gia vào tài khoản ràng buộc địa phương cũng như những hạn chế toàn cầu được xác định trong lịch trình giao tiếp.Lưu ý rằng để thực hiện thiết kế địa phương, các nhà cung cấp chỉ đòi hỏi các bộ phận của thông tin toàn cầu tạo ra bởi OEM cũng như kiến thức riêng của mình trên ECU. Về nguyên tắc, những nhà cung cấp không ảnh hưởng lẫn nhau.

Kết quả (Việt) 2:

OSEK nhóm / VDX, hai là mối quan tâm đặc biệt đối với X-by-Wire:. OSEKTime điều hành và chịu layer lỗi giao tiếp
9.3.3.1 OSEKTime
OSEKTime OS (OSEK VDX hệ điều hành / thời gian kích hoạt) [16] là hệ điều hành nhỏ được thiết kế để cung cấp các dịch vụ cơ bản cần thiết theo thời gian - các ứng dụng được kích hoạt. Đặc biệt, OSEKTime Os cung cấp dịch vụ cho công tác quản lý, xử lý interrup, xử lý lỗi.
Một ẩn-gennerated bảng dispatcher, gọi là một vòng dispatcher, kích hoạt các nhiệm vụ theo một thứ tự determinded và lặp đi lặp lại chính nó như là miễn là hệ thống đang chạy. Một số bảng điều phối khác nhau, tương ứng, ví dụ, để chế độ hoạt động khác nhau của hệ thống, có thể được xác định, nhưng việc chuyển đổi từ một bảng tiếp theo một chỉ diễn ra vào cuối của một vòng.
Nhiệm vụ không thể bị chặn chờ đợi cho một bên ngoài sự kiện, nhưng chúng có thể được preempted; một nhiệm vụ đang chạy sẽ luôn luôn được preempted bởi một nhiệm vụ được kích hoạt, và các nhà thiết kế phải đưa tranh chấp tài nguyên vào tài khoản trong trường hợp này. Một tính năng thú vị của OESKTime OS là việc theo dõi thời hạn có thể được xử lý lỗi performend rountine được gọi và các hệ điều hành được reinitialized. Trong OSEKTime OS, tỷ lệ mà tại đó các ngắt có thể xảy ra là có giới hạn, với mức giá quy định khi hệ thống được cấu hình, để giữ cho hệ thống dự đoán được.
Đối với chu kỳ truyền thông trong mạng tốn nhiều thời gian kích hoạt, cấu hình của vòng dispatcher thể làm ẩn theough một công cụ phần mềm đảm bảo tính chính xác của hệ thống.
29.3.3.2 FTCom
OSEK / VDX FTCom (fault-tolerant communcation) [17] là một đề nghị cho một lớp phần mềm cung cấp dịch vụ để tạo điều kiện phát triển các ứng dụng chịu fault- trên mạng thời gian kích hoạt. Một chức năng quan trọng của FTCom, đối với X-by-Wire, với là để quản lý các dữ liệu thừa, cần thiết để đạt được khả năng chịu lỗi (xem Phần 29.3.1.2). Từ một quan điểm thực hiện xem, đôi khi nó là thích hợp hơn để chỉ trình bày một bản sao một bản sao của dữ liệu vào ứng dụng để đơn giản hóa các mã ứng dụng và để giữ cho nó độc lập với mức độ dự phòng (ví dụ, số lượng các nút soạn FTU ). Trong thuật ngữ OSEK / VDX, các thuật toán chịu trách nhiệm cho sự lựa chọn của các chiến lược có thể là: đón bất kỳ (không im lặng nút), giá trị trung bình, pick-a-biệt-một, đa số phiếu, vv. OSEKFTCom cung cấp một cách chung chung để xác định chiến lược thoả thuận của các dữ liệu nhân rộng.
Hai dịch vụ quan trọng khác của thr FTCom là (1) quản lý đóng gói và giải nén các thư [18], đó là cần thiết nếu việc sử dụng băng thông mạng đã được tối ưu hóa và (2) cung cấp cơ chế nhắn lọc tinh thông qua dữ liệu chỉ có ý nghĩa cho các ứng dụng.
29,1 Steer-by-Wire Kiến trúc: Một trường hợp học
A Steer-by-Wire hệ thống nhằm procide hai dịch vụ chính: kiểm soát sự chỉ đạo bánh xe theo yêu cầu của người lái xe và cung cấp một cơ lực -like feedblack đến handweel. Trong phần này, chúng tôi trình bày các điểm chức năng nhìn của một hệ thống như vậy, các tính chất thời gian thực và dependablity mà phải được quan sát, và một hoạt động Steer-by-Wire hệ thống thực tế được sử dụng như một tài liệu tham khảo kiến trúc cho mục đích đánh giá. Finaally, chúng tôi sẽ tập trung vào các yêu cầu thời gian thực, và sau khi đề xuất một cách để mô hình thất bại, chúng tôi sẽ hiển thị như thế nào mỗi comonet hay hệ thống của kiến trúc tham chiếu có thể đạt được mục tiêu đáng tin cậy.
29.4.1 chức năng Mô tả một Steer-by- Hệ thống dây
Trong một hệ thống Steer-by-Wire, hai dịch vụ chính phải được provideed: các truyền động trục trước và phản lực tay quay. Vì vậy, từ một điểm chức năng của xem, điều này hàm ý hai Chức năng hoạt động chính được
buit khi các giao thức CAN tiêu chuẩn, nhưng các bộ điều khiển phải có khả năng vô hiệu hóa tự động retrans-nhiệm vụ và cung cấp các applicatino với thời gian mà tại đó các bit đầu tiên của một khung r đã gửi nhận [15]. Các togology bus của mạng, các charateristisc của supporl truyền, định dạng khung hình, cũng như tốc độ dữ liệu tối đa (1Mbits / s) được áp đặt bởi giao thức CAN. Kênh dự phòng là có thể, nhưng không được chuẩn hóa, và có người giám hộ là xe buýt thực hiện trong nút. Một minh hoạ trong hình 29.3, TCAN định nghĩa một chu kỳ cơ bản (tương đương với chu trình truyền FlexRay) như nối của một hoặc một số thời gian kích hoạt (hoặc độc quyền) các cửa sổ và một (hoặc phân xử) cửa sổ sự kiện kích hoạt. Cửa sổ độc quyền được dành cho việc truyền thời gian kích hoạt (ví dụ, các thông điệp kỳ), trong khi các cửa sổ phân xử được cai trị bởi các giao thức CAN tiêu chuẩn: truyền năng động và truy cập bus được cấp phát theo các ưu tiên của các khung. Một số chu kỳ cơ bản khác nhau của tổ chức của họ là độc quyền và phân xử các cửa sổ và các tin nhắn được gửi bên trong cửa sổ độc quyền có thể được xác định. Danh sách các chu kỳ cơ bản liên tiếp được gọi là ma trận hệ thống và được thực hiện trong vòng. Điều thú vị là, các giao thức cho phép các nút chính, nút khởi đầu chu kỳ cơ bản thông qua việc truyền tải thông điệp tham khảo, để ngăn chặn các hoạt động trong chế độ TTCAN bằng cách gửi một tin refference.
TTCAN được xây dựng trên một công nghệ nổi làm chủ và giá rẻ mà là CAN nhưng, theo quy định của tiêu chuẩn, không cung cấp dịch vụ tin cậy quan trọng như giám hộ xe buýt, thành viên phục vụ, và sự công nhận đáng tin cậy. Đó là, tất nhiên, có thể thực hiện một số các cơ chế ở các ứng dụng hoặc trung cấp, nhưng với một hiệu quả giảm. Dường như carmarker có thể xem xét việc sử dụng các TTCAN cho một số hệ thống trong một giai đoạn chuyển tiếp cho đến khi công nghệ FlexRay hoàn toàn trưởng thành.
29.3.3 Hệ điều hành và dịch vụ Middeware
Trong bối cảnh các ứng dụng ô tô, middeware là một lớp phần mềm nằm trên nền tảng ( phần cứng, hệ điều hành, các giao thức) nhằm cung cấp các dịch vụ cao cấp cho các ứng dụng để giảm thời gian cần thiết để thị trường và nâng cao chất lượng tổng thể của hệ thống. Mục đích chính của middleware là để che giấu sự phân bố của các middeware là cung cấp các dịch vụ cao cấp, và cho X-by-Wire các ứng dụng, dịch vụ liên quan đến độ tin cậy cần thiết.
Một số dự án nhằm phát triển các lớp trung gian ô tô đã được thực hiện (EAST, www.east-eea.net; AUTOSAR, http://www.autosar.org/). Để tốt nhất của kiến thức của chúng tôi, kết quả chỉ có công khai đã được sản xuất trong bối cảnh của OSEK / VDX consortium (thông tin chi tiết có thể được lấy tại http://www.osek-vdx.org), mà là một dự án của ô tô ngành công nghiệp mà mục tiêu là để buid một kiến trúc tiêu chuẩn cho các đơn vị kiểm soát -wehicle. Trong số các kết quả của Tạo mô hình phần mềm cho từng chức năng hoặc subfunction. Danh sách kết quả của các quá trình được lên kế hoạch cho ECU, có tính ràng buộc địa phương cũng như các ràng buộc toàn cầu được xác định trong kế hoạch truyền thông. Lưu ý rằng để thực hiện các thiết kế địa phương, các nhà cung cấp duy nhất đòi hỏi các bộ phận của thông tin toàn cầu được tạo ra bởi các OEM cũng như kiến thức của mình trên ECU. Về nguyên tắc, các nhà cung cấp không ảnh hưởng lẫn nhau.