Software Engineering for Automotive Systems:

Principles and Applications 1st Edition P.

Sivakumar (Editor) install download

https://ebookmeta.com/product/software-engineering-for-
automotive-systems-principles-and-applications-1st-edition-p-
sivakumar-editor/

Download more ebook from https://ebookmeta.com

We believe these products will be a great fit for you. Click
the link to download now, or visit ebookmeta.com
to discover even more!

Systems Engineering for Automotive Powertrain

Development Hannes Hick (Editor)

https://ebookmeta.com/product/systems-engineering-for-automotive-
powertrain-development-hannes-hick-editor/

Automotive Embedded Systems Key Technologies

Innovations and Applications M. Kathiresh

https://ebookmeta.com/product/automotive-embedded-systems-key-
technologies-innovations-and-applications-m-kathiresh/

Sustainable Development Goals and Migration 1st Edition

P. Sivakumar (Editor)

https://ebookmeta.com/product/sustainable-development-goals-and-
migration-1st-edition-p-sivakumar-editor/

Harmony from Discords: A Life of Sir John Denham

Brendan O Hehir

https://ebookmeta.com/product/harmony-from-discords-a-life-of-
sir-john-denham-brendan-o-hehir/
Memory and Religion from a Postsecular Perspective 1st
Edition Zuzanna Bogumi■ Editor Yuliya Yurchuk Editor

https://ebookmeta.com/product/memory-and-religion-from-a-
postsecular-perspective-1st-edition-zuzanna-bogumil-editor-
yuliya-yurchuk-editor/

Infrastructure Development and Construction Management

1st Edition J. C. Edison

https://ebookmeta.com/product/infrastructure-development-and-
construction-management-1st-edition-j-c-edison/

Business for Communicators: The Essential Guide to

Success in Corporate and Public Affairs 1st Edition
Duhé

https://ebookmeta.com/product/business-for-communicators-the-
essential-guide-to-success-in-corporate-and-public-affairs-1st-
edition-duhe/

The Haunting of Pemberton Manor 1st Edition Damien Dark

https://ebookmeta.com/product/the-haunting-of-pemberton-
manor-1st-edition-damien-dark/

Learn Python By Coding Video Games Intermediate A step

by step guide to coding in Python fast Patrick Felicia

https://ebookmeta.com/product/learn-python-by-coding-video-games-
intermediate-a-step-by-step-guide-to-coding-in-python-fast-
patrick-felicia/
Essential Echocardiography: A Review of Basic
Perioperative TEE and Critical Care Echocardiography
Timothy M. Maus (Editor)

https://ebookmeta.com/product/essential-echocardiography-a-
review-of-basic-perioperative-tee-and-critical-care-
echocardiography-timothy-m-maus-editor/
Software Engineering for
Automotive Systems
 Software Engineering for
Automotive Systems

Principles and Applications

Edited by
P. Sivakumar, B. Vinoth Kumar, and R. S. Sandhya Devi
First edition published 2022
by CRC Press
6000 Broken Sound Parkway NW, Suite 300, Boca Raton, FL 33487-2742

and by CRC Press

2 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN
© 2022 selection and editorial matter, P. Sivakumar, B. Vinoth Kumar, and R. S. Sandhya Devi; individual
chapters, the contributors
First edition published by CRC Press 2022

CRC Press is an imprint of Taylor & Francis Group, LLC

Reasonable efforts have been made to publish reliable data and information, but the author and pub-
lisher cannot assume responsibility for the validity of all materials or the consequences of their use.
The authors and publishers have attempted to trace the copyright holders of all material reproduced
in this publication and apologize to copyright holders if permission to publish in this form has not
been obtained. If any copyright material has not been acknowledged please write and let us know so
we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, trans-
mitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter
invented, including photocopying, microfilming, and recording, or in any information storage or retrieval
system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, access www.copyright.com
or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-
750-8400. For works that are not available on CCC please contact [email protected]

Trademark notice: Product or corporate names may be trademarks or registered trademarks and are
used only for identification and explanation without intent to infringe.

ISBN: 978-0-367-64785-8 (hbk)

ISBN: 978-1-032-21759-8 (pbk)
ISBN: 978-1-003-26990-8 (ebk)

DOI: 10.1201/9781003269908

Typeset in Times
by KnowledgeWorks Global Ltd.
Contents
Preface......................................................................................................................vii
Editor Biographies.....................................................................................................ix

Chapter 1 Role of AUTOSAR in Automotive Software Trends............................ 1

P. Sivakumar, A. Pavithra, S. K. Somasundarum,
P. K. Somanathan, and A. Manimuthu

Chapter 2 Use of Communication Protocols in Automotive Software

Development Process.......................................................................... 17
R. S. Sandhya Devi, P. Sivakumar, B. Vinoth Kumar,
and A. D. Buvanesswaran

Chapter 3 Bootloader Design for Advanced Driver Assistance

System................................................................................................. 31
R. S. Sandhya Devi, B. Vinoth Kumar, P. Sivakumar,
A. Neeraja Lakshmi, and R. Tripathy

Chapter 4 Advanced System Requirements for Automotive

Automation.......................................................................................... 45
H. Suneeta, M. Manohar, and S. Harlapur

Chapter 5 Software Architecture for Autonomous Trouble Code

Diagnostics in Smart Vehicles............................................................ 73
R. Rajaguru, M. Mathankumar, T. Viswanathan,
and M. Manimaran

Chapter 6 Automotive Grade Linux: An Open-Source Architecture

for Connected Cars.............................................................................. 91
P. Sivakumar, A. Neeraja Lakshmi, A. Angamuthu,
R. S. Sandhya Devi, B. Vinoth Kumar, and S. Studener

Chapter 7 Edge Node Creation Using Edge Computing Tools for

Automotive Applications................................................................... 111
P. Sivakumar, S. Bharanidharan, A. Angamuthu,
R. S. Sandhya Devi, B. Vinoth Kumar, and S. K. Somasundaram

v
vi Contents

Chapter 8 Nanosensors for Automotive Applications........................................ 125

M. Saravanan, E. Parthasarathy, J. Ajayan,
and P. Mohankumar
Index....................................................................................................................... 157
Preface
SOFTWARE ENGINEERING FOR AUTOMOTIVE
SYSTEMS: PRINCIPLES AND APPLICATIONS
This book explores the concept of principles and applications of software engineer-
ing in automotive systems for both beginners and advanced software engineers.
This book presents the state of the art, challenges, and future trends in automotive
software engineering.
The amount of automotive software in today’s cars is inevitable in the current sce-
nario, and working in the EV industry and on futuristic flying cars seems to continue
in the years to come. The Indian automobile sector is predicted to have a prominent
impact on the global economy and to be a promising employment domain for young
minds, directly or indirectly, in the forthcoming years.
This book mainly targets this group or audience such as professionals working
with automotive software and software engineering students who need to understand
the specifics of automotive software. The book covers all the basic essential aspects
of the automotive software field. As the first part, it introduces the topic related
to AUTOSAR, communication protocols used in the automotive domain, and then
it addresses the bootloader design of automotive software development, software
architecture for autonomous trouble code diagnostics, automotive grade Linux for
connected cars, edge computing for automotive applications, and nanosensors for
future automotive applications. This book serves as a reliable, complete, and well-
documented source of information on automotive software systems.
The chapters of this book will give a wide range of analysis on principles and
applications of software engineering for automotive systems. A brief introduction to
each chapter is as follows:

• Chapter 1 discusses the role of AUTOSAR in automotive software trends

and the difference between traditional and adaptive AUTOSAR.
• Chapter 2 depicts the need for a common protocol in automotive commu-
nication systems and outlines the protocols used in automotive systems.
• Chapter 3 illustrates the design of bootloader software for an ADAS system
and also discusses the security challenges faced during the updating of soft-
ware and applications in the ADAS systems.
• Chapter 4 presents the notion of design requirements generally and describes
the categories of requirements used when designing automotive software
systems by emphasizing the identification of problems or challenges faced
in automotive requirement engineering with reference to communication
and organization structure.
• Chapter 5 proposes an on-board diagnostic system that has software
architecture to solve the issues and alert the users with the help of trouble-
shooting codes.

vii
viii Preface

• Chapter 6 discusses the open-source architecture for connected cars using

automotive grade Linux to allow the accelerated creation of new technology
and applications.
• Chapter 7 discusses the application of edge computing in the automotive
domain. Usage of edge computing increases the computational capability
of the nodes, enhances the application delivery time, and reduces the scope
of congestion.
• Chapter 8 deals with nanomaterials and nanostructures used for the devel-
opment of nanosensors for automotive applications.

We are grateful to the authors and reviewers for their excellent contributions in
making this book possible.
We are grateful to CRC Press and Taylor and Francis Group, especially to
Gauravjeet Singh Reen (Senior Commissioning Editor) for the excellent collabora-
tion and support.
This edited book covers the theory and case studies of software engineering for
automotive systems. We hope the chapters presented will inspire researchers and
practitioners from academia and industry to spur further advances in the field.

Dr P. Sivakumar
Dr B. Vinoth Kumar
Ms R. S. Sandhya Devi
July 2021
Editor Biographies
P. Sivakumar received his B.E. degree in Electrical and
Electronics with I class in 2006 from Anna University. He
completed his M.E. degree in Embedded System
Technologies with I class in 2009 from Anna University
Coimbatore. He completed his Ph.D. in Electrical Engineering
with a specialization in Automotive Embedded Software in
2018 from Anna University, PSG College of Technology. His
research interests include embedded systems, model-based
design, model-based testing of automotive software, automo-
tive software development, fog and edge computing. He serves as a Guest Editor/
Reviewer of journals with leading publishers such as Inderscience and Springer.

B. Vinoth Kumar is working as an Associate Professor

with 17 years of experience in the Department of
Information Technology at PSG College of Technology.
His research interests include computational intelligence,
digital image processing, and embedded systems. He is
the author of more than 40 papers in refereed journals and
international conferences. He has edited four books with
reputed publishers such as Springer and CRC Press. He
serves as a Guest Editor/Reviewer of many journals with
leading publishers such as Inderscience and Springer.

R. S. Sandhya Devi received her B.E. (Electronics and

Communication Engineering) from Avinashilingam
University, Coimbatore, Tamil Nadu, India. She com-
pleted her M.E. (Embedded Systems) at Anna University
of Technology, Coimbatore, Tamil Nadu, India. She is an
Assistant Professor at Kumaraguru College of Technology.
Her areas of interest include embedded system design and
ARM processors. She published her project in a journal
and international conference.

ix
 1 Role of AUTOSAR
in Automotive
Software Trends
P. Sivakumar and A. Pavithra
Department of EEE, PSG College of Technology,
Coimbatore, India

S. K. Somasundarum
Department of IT, PSG College of Technology,
Coimbatore, India

P. K. Somanathan
ZF Friedrichshafen AG, Solihull, England,
United Kingdom

A. Manimuthu
Cybersecurity Centre @ NTU (CYSREN), Nanyang
Technological University, Singapore

CONTENTS
1.1 Introduction....................................................................................................... 2
1.1.1 Key Drivers............................................................................................ 3
1.1.2 Key Restraint......................................................................................... 4
1.2 Classic Platform................................................................................................. 4
1.3 Adaptive Platform..............................................................................................4
1.4 Market for Automotive Software and Core Technologies.................................5
1.4.1 Consolidation of ECUs.......................................................................... 5
1.4.2 Updates Received OTA......................................................................... 5
1.4.3 Role of Artificial Intelligence (AI) in Automotive................................ 5
1.4.4 Mission of AUTOSAR..........................................................................5
1.4.5 Purpose of AUTOSAR.......................................................................... 6
1.4.6 Methodology..........................................................................................6
1.5 AUTOSAR’s Highlights.................................................................................... 6
1.5.1 Enhance Security and Safety................................................................. 6
1.5.2 Connectivity Should Be Improved........................................................6
1.5.3 Develop Service Life Enhancements That Are Adaptable....................6

DOI: 10.1201/9781003269908-1 1
2 Software Engineering for Automotive Systems

1.6 AUTOSAR Architecture................................................................................... 6

1.6.1 BSW Architecture................................................................................. 7
1.6.1.1 Microcontroller Abstraction Layer (MCAL).......................... 7
1.6.1.2 ECU Abstraction Layer........................................................... 7
1.6.2 Service Layer.........................................................................................8
1.6.3 AUTOSAR RTE Layer.......................................................................... 8
1.6.4 Application Layer..................................................................................8
1.7 Adaptive AUTOSAR......................................................................................... 8
1.7.1 Service-Oriented Architecture (SOA)................................................. 10
1.7.2 Programming Language...................................................................... 10
1.7.3 OS........................................................................................................ 10
1.8 Adaptive AUTOSAR Architecture.................................................................. 10
1.8.1 Autonomous Driving........................................................................... 11
1.8.2 Connected Vehicles............................................................................. 11
1.8.3 Vehicle Electrification......................................................................... 12
1.8.4 Classic and Adaptive AUTOSAR Are Complementary...................... 12
1.8.5 Importance of AUTOSAR in Car Industry......................................... 12
1.8.6 AUTOSAR-Incorporated Applications............................................... 13
1.8.7 Organization........................................................................................ 13
1.9 Advantages....................................................................................................... 14
1.10 Applications..................................................................................................... 14
1.11 Conclusion....................................................................................................... 14
References................................................................................................................. 15

1.1 INTRODUCTION
Automotive open system architecture (AUTOSAR) is a plug-and-play platform
architecture that allows vehicle original equipment manufacturers (OEMs) and
Tier 1 provider to increase electronic control unit (ECU) programming efficiency,
reduce development costs, and prevent re-advancement of identical ECU software
program elements for the same vehicle applications. It is a new and evolving way
of describing a layered programming system. AUTOSAR aims to enhance com-
plexity management of built-in E/E architectures by allowing OEMs and vendors
to reuse and swap software modules (Devi, R. S., Sivakumar, P., & Balaji, R.
2018). AUTOSAR aims to standardize the structure of ECU. AUTOSAR sets the
stage for cutting-edge digital systems to improve efficiency, safety, and protection,
among other things.
Automotive attributes such as independent driving, vehicle-to-everything
(V2X) availability, over-the-air (OTA) refreshes, prescient support, and a wide
range of current focuses are fundamentally founded on in-vehicle programming
capacities. Each ECU must be functional in order for each of these features to
operate flawlessly and to take into account continuous in-vehicle capabilities. To
help complicated vehicular tasks, cutting-edge top-of-the-line engines have up
to a hundred ECUs that communicate with each other using Ethernet, Controller
Area Networking (CAN), FlexRay, CAN Flexible Data-Rate (FD), and other
Role of AUTOSAR in Automotive Software Trends 3

communication protocols (Elbahnihy, A., Safar, M., & El-Kharashi, M. W. 2020).

OEMs previously used ECU software applications that run on a variety of platforms.
There was no fashionable software program design being used by level 1 or Tier 1
providers and its merchants to coordinate ECU programming with OEMs previ-
ously. As a result, every time an OEM wanted to move to a different grade 1 or Tier
1 provider, or vice versa, the transition used to be extremely difficult. As a result, the
new provider’s decision to run an ongoing test in the middle via its formation pres-
ence period was almost irrational.
Tier 1 vehicle providers, semiconductor manufacturers, software providers,
instrument providers, and others formed the AUTOSAR consortium in 2003 to
enhance OEM-Tier 1 provider cooperation, improve ECU programming satisfaction,
and reduce expenses and time (Honekamp, U. 2009). AUTOSAR is a flexible and
standardized vehicle-programming program that aids in the optimization of inter-
faces among utility programming and vital vehicular features as well as the estab-
lishment of continuous ECU software program design throughout all AUTOSAR
members. AUTOSAR can provide members with intrinsic benefits that enable them
to monitor highly complicated E/E in-vehicle constraints, such as easy integration
and exchange of features in complicated ECU people groups, and oversight of the
complete item lifecycle (Kim, J. W., Lee, K. J., & Ahn, H. S. 2015; Sandhya, D. R.,
Sivakumar, P., & Balaji, R. 2019). AUTOSAR has given four chief arrivals of the
normalized vehicle software structure and one arrival of acceptance tests about its
classical platform since 2003. AUTOSAR’s constructs are divided into three stages:

Stage I (2004–2006) Basic enhancements to general environment

Stage II (2007–2009) Standardization of structure and procedure
Stage III (2010–2013) Rehabilitation and improvements as required

In 2013, the AUTOSAR group launched an uninterrupted working mode for its
traditional model in order to maintain the well-known while providing selected
upgrades. The fundamental advancement exercises had been posted along these lines
in some kind of a shared arrival of AUTOSAR classic, foundation, and adaptive,
with release 18.10 in October 2018.The automotive software program is a collection
of instructible data development that is used to carry out computerized in-vehicle
operations. In-vehicle microcontroller’s software is often referred to as automo-
tive software (Sivakumar, P., Vinod, B., Devi, R. S. 2016). Telemetry, multimedia,
power train, body manipulation and convenience, connectivity, and enhanced driver
assistance systems (EDAS) are examples of computerized in-vehicle implementa-
tions. Automotive software refers to the hardware and interfaces that run in-vehicle-
integrated functions walkthrough on a machine (Mahmud, N. et al 2018) (Sivakumar,
P., Vinod, B., Devi, R. 2016).

1.1.1 Key Drivers

• Vehicles with EDAS are becoming more popular.
• The use of connected car services is becoming more widespread.
• Involvement of cutting-edge technology for modern user interfaces.
4 Software Engineering for Automotive Systems

1.1.2 Key Restraint

• Inability to build software platforms using standard protocols
• Inadequately linked infrastructure
• Vehicle device’s automotive software troubleshooting and repair

1.2 CLASSIC PLATFORM

The AUTOSAR Exemplary Stage design perceives the most significant degree of
interpretation among three programming frameworks that operate on a microcon-
troller (Arts, T. et al 2015):

1. Application software component (ASW)

2. Runtime environment (RTE)
3. Basic software (BSW)
• The ASW frame work is mostly hardware-agnostic.
• Correspondence between programming sections and permission to BSW
by methods for RTE.
• The RTE covers the whole device interface.
• BSW is made up of three layers, each with its own set of dynamic drivers:
– Administrations, ECU reflection, and microcontroller consideration.
– Administrations are categorized other than interested in valuable
social affairs addressing the establishment for system, memory, and
correspondence organizations.

1.3 ADAPTIVE PLATFORM

AUTOSAR-based adaptive platform implements the AUTOSAR runtime for adap-
tive applications (ARA) (Fürst, S., & Bechter, M. 2016). Services and Application
Programming Interface (APIs) are the two types of connections required. The
framework is made up of functional clusters that are integrated into services as well
as the adaptive AUTOSAR foundation.
Functional clusters…

• Compile the functions of the adaptive framework,

• Organize the criteria specifications into groups, and
• Illustrate the software platform’s actions from a network and an application
standpoint.
• The adaptive platform’s final SW specification of the programming model
allows for a minimum of one service per (virtual) unit, although services
can be spread through the vehicle arrangement.

The environment AUTOSAR API for agile technology platforms and adaptive users
at runtime is superior to the AUTOSAR classic platform.
Role of AUTOSAR in Automotive Software Trends 5

1.4 MARKET FOR AUTOMOTIVE SOFTWARE

AND CORE TECHNOLOGIES
1.4.1 Consolidation of ECUs
The primary goal of ECU consolidation is to reduce the number of pieces of hard-
ware within the vehicle. This is usually accomplished by virtualizing hardware with
software through a guest or host operating system (OS) architecture (Ryu, H., Jnag,
S. Y., & Lee, W. J. 2013). Many vehicles have a mix of safety-significant and non-
safety-significant structures. Unified cockpits are an example of this, in which the
safety-significant (able to run on RTOS) and the IVI device (able to run on Linux OS)
share the similar hardware, which includes storage unit.

1.4.2 Updates Received OTA

Automotive OTA improvements are a method of communicating clinical and func-
tional info from a virtual server to interior structures including parameters of the
vehicle in order to upgrade a variety of car applications such as ECU algorithms and
multimedia without having to visit a workshop, vendor warehouse, or vendor loca-
tion. Firmware OTA (FOTA) and Software application OTA (SOTA) updates are
two forms of OTA improvements.

1.4.3 Role of Artificial Intelligence (AI)

in Automotive

In automobiles, electronics structures and strategies based on AI can be used. The

machine’s software is in charge of performing difficult operations and delivering
learning capabilities. Many trends have emerged in the field of AI software applica-
tions, frameworks, and associated developer tools in recent years. Companies like
Microsoft, Alphabet, and Intel are among the pioneers in AI software development.
The majority of the companies involved in the AI logistics market’s software appli-
cation segment are based in North America.

1.4.4 Mission of AUTOSAR
The AUTOSAR association was established for the purpose of standardizing a typi-
cal device, critical machine features, and useful interfaces. This allows advance-
ment allies to organize, exchange, reuse, and pass functions within an automobile
group, dramatically increasing their production performance. AUTOSAR moves the
change in perspective from just an ECU-based to a restriction contraption configura-
tion effort in vehicle programming improvement and makes the organization of the
constantly changing programming and E/E multifaceted nature for production and
financial aspects.
6 Software Engineering for Automotive Systems

1.4.5 Purpose of AUTOSAR
AUTOSAR is a global development collaboration of vehicle-interested parties that
was established in 2003. Its aim is to develop and implement a flexible and modular
software program framework in automobile computer-assisted control systems.

1.4.6 Methodology
The system configuration description includes all framework records as well as
information shared among various ECUs (for example, meaning of transport or
BUS signals). The ECU-specific statics contain the statics from the configuration
management description that are needed for an exact ECU (for instance, those
alarms in which a remarkable ECU is approaching). The ECU setup summary is
a file that contains all of the essential computer program setup information for a
specific ECU.

1.5 AUTOSAR’S HIGHLIGHTS

1.5.1 Enhance Security and Safety
• Standard fault and threat scenarios are supported.
• Extend the testing and verification process.
• Streamline procedures.

1.5.2 Connectivity Should Be Improved

• Growing the number of mainstream cloud services.
• Consider the AUTOSAR AppStore.
• Connectivity to zone smartphones and control devices should be allowed.

1.5.3 Develop Service Life Enhancements That Are Adaptable

• Enhance modularity
• Specify the cluster interfaces
• Ensure that funds are available to complete the device definition

1.6 AUTOSAR ARCHITECTURE

In the classic platform shown in Figure 1.1, the layered architecture supports

• Abstraction of hardware
• Runnable and job scheduling (OS) AUTOSAR
• Services for diagnosis and therapeutics
• Services for security and safety

AUTOSAR is open framework engineering for vehicle programming advancement

and gives guidelines to creating normal vehicle programming applications. It is a
Role of AUTOSAR in Automotive Software Trends 7

FIGURE 1.1 AUTOSAR architecture

growing and evolving standard that defines a layered architecture for software. The
AUTOSAR tier, for example, is separated into three layers and operates upon the
microcontroller. Let’s take a closer look at these:

1.6.1 BSW Architecture

The AUTOSAR simple software structure is made up of many software modules
organized in layers and shared by all AUTOSAR ECUs. It is therefore the com-
pany that developed BSW would share it with other companies working on engines,
gearboxes, and other components. The BSW program architecture of AUTOSAR is
made up of three layers:

1.6.1.1 Microcontroller Abstraction Layer (Mcal)

MCAL implements the special microcontroller interface and is also referred to as the
hardware abstraction layer. MCAL offers drivers such as gadget drivers, diagnostic
drivers, storage drivers, conversation operators (LIN, CAN, Ethernet, etc.), I/O driv-
ers, and more by implementing software layers across registers with the microcon-
troller 1 (Dafang, W. et al 2010).

1.6.1.2 ECU Abstraction Layer

The ECU abstract layer’s main goal is to make ECU-particular administrations more
flexibly prominent software layers. This level and its operators are part of the micro-
controller and are installed on the ECU equipment. They provide access to all of
the ECU’s peripherals and devices, which aid functionalities such as memory, com-
munication, and I/O.
8 Software Engineering for Automotive Systems

1.6.2 Service Layer
The highest layer in the AUTOSAR core system design is the provider layer. The
provider layer creates a working system that operates from the product (S/W) layer to
a base microcontroller. The OS serves as a link between the microcontroller as well
as the application layer, and it can schedule utility tasks. Network services, storage
services, networking services, ECU country management, therapeutics services, and
other services are all handled by the carrier layer in BSW. The service layer sits on
top of the ECU abstraction layer, in the key neutral of the equipment, and is respon-
sible for providing the application with the required BSW execution. The RTE layer
separates the core software from the application software (Kienberger, J. et al 2014).

1.6.3 AUTOSAR RTE Layer

RTE is a middleware layer of the AUTOSAR software program engineering that
provides verbal trade contributions for the application software (Kum, D. et al 2008).
It sits between the BSW and software layer (Park, G. 2008).

1.6.4 Application Layer
The AUTOSAR programming structure’s application layer facilitates the imple-
mentation of customized functionalities. The application layer is made up of client-
defined programming segments that communicate with sensors and actuators using
BSW. It also includes a variety of software components and applications that per-
form precise tasks according to instructions. The AUTOSAR programming layer
is made up of three parts: (1) application programming segments, (2) programming
segment ports, and (3) port interfaces. AUTOSAR ensures consistent interfaces for
utility layer programming program components, and the utility layer programming
program components assist in the development of basic applications to support auto-
mobile capabilities. Methodologies to use a virtual Function Bus for specific ports
promote communication between computing components (Dafang, W. et al 2010).
Furthermore, these ports make it easier for computing components and BSW to
communicate. The abovementioned structure of AUTOSAR is its traditional phase,
which reinforces ongoing assurance requirements and imperatives (Webers, W.,
Thörn, C., & Sandkuhl, K. 2008). The critical stage is suitable for supporting pur-
poses in the field of system administration and well-being because of the microcon-
troller, which allows ECUs to handle automobile sensors and devices.

1.7 ADAPTIVE AUTOSAR

The adaptive platform’s improvement is becoming increasingly important and urgent.
The truly automatic essence of driving is a true aim in this. When vehicles become
halfway responsible of driving, it is essential to have an immediate conversation
with the system and cloud servers (Singh, G., Kamath, N., & Sharma, R. K. 2018).
In addition, related vehicles and V2X operations necessitate collaboration with the
off-board systems. As a result, the on-board discussion must be extremely impen-
etrable and aid mobile integration, non-AUTOSAR structure incorporation, and
Role of AUTOSAR in Automotive Software Trends 9

cross-domain computing platform levels. Cloud-based administrations necessitate

exact protection measures as well. This allows for remote notifications, such as those
received over the air. AUTOSAR recently standardized the AUTOSAR adaptive plat-
form to aid in the consistent distribution of client applications and to provide the
proper environment for those that need high-end computing (Aust, S. 2018). This is a
computer that runs under the POSIX standard. Its most important feature is admin-
istration-based correspondence. The adaptive platform is made up of specifications
and code. In Compared to Traditional AUTOSAR Adpative AUTOSAR designed and
implemented which shortens approval times and reveals secret concepts. It is open to
all of the organization’s associations.
The AUTOSAR consortium has provided a game-evolving arrangement, which
provide efficient work with less time and money contributed than previously. This
manner gave OEMs the freedom to choose software program from more than one
provider and they suggest higher-quality goods. AUTOSAR’s equipment and tech-
niques significantly increase the quality of embedded programming. AUTOSAR’s
concept is simply the start of a long activity that provides time to implement.
Patterns can be used by the automotive industry to refine this software application
and enhance its benefits.
From 2003 to 2015, Classic AUTOSAR evolved into a mounted platform that per-
formed admirably well while running 60–80 ECUs in an automobile. Electrification
surged with the advancement of Internet of Things (IoT)-based vehicle attributes like
V2X network and autonomous driving, and that as an outcome, a huge demand for
assisting features and devices was generated in the sector (Swetha, S., & Sivakumar,
P. 2021). The current AUTOSAR platform has proven inadequate to accommodate
these megatrends, necessitating the creation of stronger new structures and more ver-
satile E/E structure. The adaptive AUTOSAR architecture was implemented to sup-
port these features, and the first release of the AUTOSAR scalable model took place
in 2017. A central software server that supports high-performance computing comes
with an adaptive AUTOSAR structure. Ethernet-based ECUs support real-time func-
tionality in this unit. The adaptive AUTOSAR is modular, with a versatile architec-
ture that allows it to alter functions during the vehicle’s lifecycle. This enables OEMs
to introduce state-of-the-art software elements in a vehicle and substitute it in the
environment as required. AUTOSAR versatile engineering is based on all cutting-
edge vehicle applications such as infotainment, V2X, prescient operation, vehicle
applications, ADAS highlights with RADAR and LIDAR sensors, camera, zap, map
updates, and the sky is the limit from there. The adaptive platform of AUTOSAR is a
stable, robust, and incremental platform that lets OEMs design feature-packed vehi-
cles to direct future automotive trends (Soltani, M., &Knauss, E. 2015). The adaptive
platform makes use of smart ECUs and enables upgrading over the life cycle of the
vehicle for high-end vehicle purposes. To define the adaptive AUTOSAR platform, its
functionality, layout, and its use cases, read this article. For OEMs and their custom-
ers, car frameworks have grown dramatically and inclinations such as autonomous
driving, prescient assistance, V2X availability, OTA updates, and vehicle jolt are a
high concentration. The use cases posed by these trends are reshaping the technical
experience across subsystems of cars. While the simple AUTOSAR platform helped
OEMs and their suppliers with standardized software systems by using the frequent
architecture of ECU software program architecture, elevated reuse, and unified
10 Software Engineering for Automotive Systems

language methodology, it also faced constraints to support complex, efficient, and

bendy E/E architecture needed for next-gen automotive trends (Wu, R. et al 2010).
Then again, the AUTOSAR flexible stage is adaptable, vigorous, and steady. It pro-
vides bendy tech configuration that can be modified over the life cycle of the vehicle
to assist self-sufficient driving, V2X networking, and various high-end apps. The
AUTOSAR adaptive platform provides software developers with a powerful pro-
gramming interface called AUTOSAR runtime for ARA. The following are some
of the requirements that will enable the AUTOSAR adaptive platform to be used in
future automotive applications (Webers, W., Thörn, C., & Sandkuhl, K. 2008).
High-performance computing

1. Easy configuration and diagnosis

2. Faster development cycles/rapid prototyping
3. Multicore processor support
4. Interoperability with classic AUTOSAR platform

1.7.1 Service-Oriented Architecture (SOA)

AUTOSAR adaptive platform focuses on flexibility and scalability and is for that
reason designed over SOA. SOA approves designing bendy ECUs software that helps
in decreasing the complexity and improving reusability and portability of the soft-
ware program components.

1.7.2 Programming Language
Adaptive AUTOSAR relies upon on C 14 language standard. Usually, C language
is the top focal point to boost any vehicle application; however, the complexity of
the adaptive platform led to the adoption of C. Compared to C language, C offers a
higher mechanism for records encapsulation and helps massive and allotted systems
in a higher manner.

1.7.3 OS
AUTOSAR adaptive platform runs on POSIX-based (PSE51). POSIX stands for
“Portable Operating System Interface” through which one can access the OS.
Through PSE 51, about 300 APIs can be used, which allows higher portability.
POSIX-based totally (PSE51) additionally helps preemptive multitasking and allows
a dynamic variety of tasks.

1.8 ADAPTIVE AUTOSAR ARCHITECTURE

Adaptive AUTOSAR architecture consists of four most important layers:

1. Hardware/Virtual Machine: This is the first layer of the architecture and

is referred to as a digital machine, on which the adaptive AUTOSAR basis
is fashioned and ARAs.
Role of AUTOSAR in Automotive Software Trends 11

2. Adaptive AUTOSAR Foundation: The adaptive AUTOSAR basis carries

the simple offerings for the applications, which abstracts the hardware and
provides an opportunity for applications to run efficiently.
3. Adaptive AUTOSAR Services: Adaptive AUTOSAR services manage the
conversation between the adaptive AUTOSAR applications.
4. ARAs: The adaptive utility runs on top of the architecture and uses the
services supplied by using ARA (AUTOASR runtime for ARAs) as shown
in Figure 1.2. ARA affords APIs for adaptive AUTOSAR services like soft-
ware configuration management, security management, and diagnostics.

The features and architecture mentioned above explain the technical background of
the AUTOSAR adaptive platform to support future use cases of automotive trends
mentioned below.

1.8.1 Autonomous Driving
To plan the points of independent driving, automobiles have to have sensible ECUs
that can deal with the giant quantity of data. Autonomous motors have to commu-
nicate with the changing surrounding environment, manipulate alerts from the hun-
dreds of in-vehicle sensors, and deal with the massive data that flows in the clever
ECUs. Intelligent ECUs require in-vehicle software to be up to date in the course of
a vehicle’s existence cycle due to evolving exterior structures and increased function-
ality. Autonomous automobiles of stage four and level five (partially or independent
vehicles) use tremendously complex algorithms, maps, and sensor fusion to feature
an adaptive platform that helps in enabling them all (Parekh, T. et al 2021).

1.8.2 Connected Vehicles

Vehicle connectivity is the next massive aspect that is rising exceptionally. Vehicle-
to-vehicle (V2V), V2X, remote diagnostics, and cloud-based analytics are some of

AUTOSAR Runtime for Adaptive Application

API API Adaptive AUTOSR Services

Execution
Management Service Service Service
Software
API Security
Configuration Diagnostics
Operating Management
Management
system (*) Persistency

API API API API

Platform
Logging and Hardware
Health Communications
Tracing Acceleration
Bootloader Management
Adaptive AUTOSR Foundation
(Virtual) Machine / Hardware

FIGURE 1.2 AUTOSAR runtime for adaptive applications

12 Software Engineering for Automotive Systems

the hot tendencies in the linked vehicle paradigm (Subburaj, S. D. R. et al 2021). V2X
systems require invulnerable communication with different cars and off-board sys-
tems, which might also be non-AUTOSAR systems. Next-gen motors will be related
to different vehicles, smartphones, traffic infrastructure, etc., and in-vehicle V2X
applications will be required to be up to date OTA; this is the place the AUTOSAR
adaptive platform assists.

1.8.3 Vehicle Electrification
The other rising vehicle tendencies like automobile electrification require a complete
system-level approach in design, as its single function can create an effect on other
necessary functions. The features such as EV charging, charger conversation, and
hybrid electric powered motors are related to functionalities of electric cars only
and wanted to be addressed through sensible ECUs distinctively than in gasoline-
powered vehicles. The electric powered automobiles require extraordinary units
of ECU software and options when it comes to V2V, V2X connectivity, physique
area controller, and OTA software program updates. The AUTOSAR is the
solely successful platform that can meet the incremental requirements of electric
automobiles in communication, connectivity, and other areas.

1.8.4 Classic and Adaptive AUTOSAR Are Complementary

While AUTOSAR traditional platform supports basic car features such as ignition,
the front, and rear mild management, engine control, torque control, etc., AUTOSAR
adaptive platform is an evolving platform, which requires excessive overall perfor-
mance computers that are embedded with clever ECUs to empower infotainment,
HMI, ADAS functions, connectivity, and more (Sivakumar, P., 2020). The perfor-
mance of updating the ECU software program over the air will remove the prob-
ability of introducing new ECUs to the vehicle. The AUTOSAR adaptive platform
has given the advantage to OEMs to launch their high-end vehicles with minimal
functionalities. The adaptive platform’s scalability and versatility allow automobiles
to enhance their purposes and aspects over the vehicle’s life cycle, which is how
they improve their efficiency eInfochips of AUTOSAR facilities. As an AUTOSAR
partner, eInfochips (An Arrow Company) assists Tier 1 suppliers and automobile
OEMs with a variety of AUTOSAR-related services, including the creation, imple-
mentation, and testing of AUTOSAR simple software modules, the AUTOSAR
stack software’s implementation from the suppliers, platform software upgrades to
latest AUTOSAR specifications as per requirements, and much more (Jayan, J., &
Srinivasan, G. 2019).

1.8.5 Importance of AUTOSAR in Car Industry

AUTOSAR enables new digital systems to be introduced that can enhance protec-
tion, environmental friendliness, and overall efficiency. The common strategy is
to prepare the sector for future applied sciences and reduce fees without losing
results.
Role of AUTOSAR in Automotive Software Trends 13

1.8.6 AUTOSAR-Incorporated Applications
AUTOSAR is common in the industry for the communication of automotive systems.
AUTOSAR specifications describe a layer of BSW that includes services that com-
municate with precise hardware but have a general application interface. EMCOS
AUTOSAR is the eMCOS-compliant AUTOSAR Classic Platform profile, a real-
time running computer (real-time systems or embedded systems with integrated
RTOs) that was once the first such product available on the market to provide flexible
support ranging from single-core to multi-core processors. A standardized interface
is an interface that is predefined in the C language by using the AUTOSAR specifica-
tion as an API. It is used in an ECU between BSW modules, between the RTE and the
operating machine, or between the RTE and the BSW module. AUTOSAR is distinct
from all other embedded programming paradigms. The reason for the distinction
is that in uniform layers, distinguishing the output from complete ECU is needed.
Besides, via the modules or software program components, this split operation often
determines common interfaces. This standardization has a number of advantages,
including scalability to individual devices, acknowledgment of practicable safety
requirements, integration of multiple providers’ functional fashions, and reusable
software components. Aside from that, AUTOSAR is public architecture. A certifi-
cate from the board is required to be used for business purposes. A developer cannot
sell software under the AUTOSAR brand without the certificate from the board.

1.8.7 Organization
• A key associate
• Strategic associate
• Exclusive partnership
• Associate partner
• Development partner

The founding partners BMW, Bosch, Continental, Daimler AG, Ford, General
Motors, PSA Peugeot Citroen, Toyota, and Volkswagen are among the attendees’ key
associates. These companies are in charge of the AUTOSAR improvement partner-
ship’s organization, administration, and management. The Executive Board estab-
lishes the standard method and roadmap within this core. The steering committee
oversees non-technical operations such as partner admission, public family mem-
bers, and contractual issues. For that reason, the Chairman and Deputy Chairman,
each designated for a year, represent the Steering Committee. The contact with the
outdoor environment is taken over by the AUTOSAR spokesperson. Strategic asso-
ciates are selected from the circle of premium partners for a two-year term and assist
the undertaking chief group in a variety of technological, operational, and day-to-
day processes. They also provide new strategic inputs to the project manager round.
Participants in the standard and community development contribute to work appli-
cations that are organized and supervised by the Project Manager Team, which was
formed with the help of the core partners. The popular files AUTOSAR has already
released are being used by associate partners. Attendees are actively working on
14 Software Engineering for Automotive Systems

academic programs and non-profit projects. The AUTOSAR production alliance

now includes over 270 organizations as of mid-2019.

1.9 ADVANTAGES
• Hardware and software are largely unrelated to one another.
• Horizontal layers will decouple development (through abstraction), reduc-
ing development time and costs.
• Software reusability improves consistency and performance.
• Create a development distribution system among suppliers.
• Improved design versatility allows you to compete on creative features.
• Make program and device integration easier.
• Lower the total cost of software creation.
• Enable more efficient variant handling.
• Share software modules between OEMs.
• Improve application development performance.
• Come up with new business models.
• Work in the planning process.
• Integrate software into a larger tool environment.
• Use normalized applications to enable new business opportunities.
• Gain a clear understanding of how automotive software is created.

1.10 APPLICATIONS
• In 2008, the first automobiles with AUTOSAR technology were introduced
to the market. Today, the brand is well-known, and AUTOSAR products
are successfully used in a variety of vehicle ventures. The large proportion
of the world’s automakers is AUTOSAR partners, and the significant pro-
portion of them are either using or planning to use AUTOSAR technology.
Auto manufacturing by AUTOSAR OEM associates accounts for roughly
80% of global demand.
• Because of the standardization, there would be more component reuse.
Expenses for skill enhancement can be spread out over a longer period of
time. Another issue that reduces costs is the interchangeability of supplier
solutions. As a result, there is more opposition.
• AUTOSAR emphasizes on technological advancements rather than busi-
ness models. In the marketplace, there will be some answers to this query.

1.11 CONCLUSION
AUTOSAR encourages a broad impact on the advancement of electronics automation.
It assembles electronics, OEMs, semiconductors, and a variety of automation compa-
nies to produce a variety of creative products. Elucidation suggested by AUTOSAR
methodology extensively reconciles with modern evolution since enhanced effective-
ness with considerably diminished time and money plunged provides the liberty to
OEMs to select software alternatives from multiple suppliers.
Role of AUTOSAR in Automotive Software Trends 15

REFERENCES
(Devi, R. S., Sivakumar, P., & Balaji, R. 2018) Devi, R. S., Sivakumar, P., & Balaji, R. 2018.
AUTOSAR Architecture Based Kernel Development for Automotive Application.
In International Conference on Intelligent Data Communication Technologies and
Internet of Things (pp. 911–919).
(Arts, T., Hughes, J., Norell, U. 2015) Arts, T., Hughes, J., Norell, U., & Svensson, H. 2015. Testing
AUTOSAR Software with QuickCheck. In 2015 IEEE Eighth International Conference
on Software Testing, Verification and Validation Workshops (ICSTW) (pp. 1–4).
(Kienberger, J., Minnerup, P., Kuntz, S 2014) Kienberger, J., Minnerup, P., Kuntz, S.,
& Bauer, B. 2014. Analysis and Validation of AUTOSAR Models. In 2014 2nd
International Conference on Model-Driven Engineering and Software Development
(MODELSWARD) (pp. 274–281).
(Parekh, T., Kumar, B. V., Maheswar, R. 2021) Parekh, T., Kumar, B. V., Maheswar, R.,
Sivakumar, P., Surendiran, B., & Aileni, R. M. (2021). Intelligent Transportation
System in Smart City: A SWOT Analysis. In Challenges and Solutions for Sustainable
Smart City Development (pp. 17–47). Springer, Cham.
(Mahmud, N., Rodriguez-Navas, G., Faragardi, H. 2018) Mahmud, N., Rodriguez-Navas,
G., Faragardi, H., Mubeen, S., & Seceleanu, C. 2018. Power-aware Allocation of
Fault-tolerant Multirate AUTOSAR Applications. In 2018 25th Asia-Pacific Software
Engineering Conference (APSEC) (pp. 199–208).
(Webers, W., Thörn, C., & Sandkuhl, K. 2008) Webers, W., Thörn, C., & Sandkuhl, K. 2008.
Connecting Feature Models and AUTOSAR: An Approach Supporting Requirements
Engineering in Automotive Industries. In International Working Conference on
Requirements Engineering: Foundation for Software Quality (pp. 95–108).
(Fürst, S., & Bechter, M. 2016) Fürst, S., & Bechter, M. 2016. AUTOSAR for Connected
and Autonomous Vehicles: The AUTOSAR Adaptive Platform. In 2016 46th annual
IEEE/IFIP International Conference on Dependable Systems and Networks Workshop
(DSN-W) (pp. 215–217).
(Subburaj, S. D. R., Kumar, V. V., Sivakumar, P. 2021) Subburaj, S. D. R., Kumar, V. V.,
Sivakumar, P., Kumar, B. V., Surendiran, B., & Lakshmi, A. N. 2021. Fog and Edge
Computing for Automotive Applications. In Challenges and Solutions for Sustainable
Smart City Development (pp. 1–15). Springer, Cham.
(Honekamp, U. 2009.) Honekamp, U. 2009. The Autosar XML Schema and Its Relevance for
AUTOSAR Tools. IEEE Software, 26(4), 73–76.
(Elbahnihy, A., Safar, M., & El-Kharashi, M. W. 2020) Elbahnihy, A., Safar, M., &
El-Kharashi, M. W. 2020. Hardware-accelerated SOME/IP-based Serialization for
AUTOSAR Platforms. In 2020 15th Design & Technology of Integrated Systems in
Nanoscale Era (DTIS) (pp. 1–2).
(Dafang, W., Jiuyang, Z., Guifan, Z. 2010) Dafang, W., Jiuyang, Z., Guifan, Z., Bo, H.,
& Shiqiang, L. 2010. Survey of the AUTOSAR Complex Drivers in the Field of
Automotive Electronics. In 2010 International Conference on Intelligent Computation
Technology and Automation (Vol. 3, pp. 662–664).
(Ryu, H., Jnag, S. Y., & Lee, W. J. 2013) Ryu, H., Jnag, S. Y., & Lee, W. J. 2013. AUTOSAR Unit
Testing Approach Based on Virtual Prototyping for Software Components. In 2013 Fifth
International Conference on Ubiquitous and Future Networks (ICUFN) (pp. 114–116).
(Sivakumar, P., Vinod, B., Devi, R. 2016) Sivakumar, P., Vinod, B., Devi, R. S., & Divya,
R. (2016). Deployment of Effective Testing Methodology in Automotive Software
Development. Circuits and Systems, 7(9), 2568–2577.
(Wu, R., Li, H., Yao, M. 2010) Wu, R., Li, H., Yao, M., Wang, J., & Yang, Y. 2010. A Hierarchical
Modeling Method for AUTOSAR Software Components. In 2010 2nd International
Conference on Computer Engineering and Technology (Vol. 4, pp. V4–184).
16 Software Engineering for Automotive Systems

(Singh, G., Kamath, N., & Sharma, R. K. 2018) Singh, G., Kamath, N., & Sharma, R. K. 2018.
Implementing Adaptive AUTOSAR Diagnostic Manager with Classic Diagnostics as
APIs. In 2018 Second International Conference on Intelligent Computing and Control
Systems (ICICCS) (pp. 894–898).
(Aust, S. 2018) Aust, S. 2018. Paving the Way for Connected Cars with Adaptive AUTOSAR
and AGL. In 2018 IEEE 43rd Conference on Local Computer Networks Workshops
(LCN Workshops) (pp. 53–58).
(Sivakumar, P., Vinod, B., Devi, R. S. 2016) Sivakumar, P., Vinod, B., Devi, R. S., & Divya,
R. 2016. Novelty Testing Measures and Defect Management in Automotive Software
Development. Australian Journal of Basic and Applied Sciences, 10(1), 607–613.
(Kim, J. W., Lee, K. J., & Ahn, H. S. 2015) Kim, J. W., Lee, K. J., & Ahn, H. S. 2015.
Development of Software Component Architecture for Motor-driven Power Steering
Control System Using AUTOSAR Methodology. In 2015 15th International Conference
on Control, Automation and Systems (ICCAS) (pp. 1995–1998).
(Kum, D., Park, G. M., Lee, S. 2008) Kum, D., Park, G. M., Lee, S., & Jung, W. 2008.
AUTOSAR Migration from Existing Automotive Software. In 2008 International
Conference on Control, Automation and Systems (pp. 558–562).
(Park, G., Kum, D., Jin, S. 2008) Park, G., Kum, D., Jin, S., & Jung, W. 2008. Implementation
of AUTOSAR I/O Driver Modules for a SSPS System. In 2008 International Conference
on Control, Automation and Systems (pp. 1451–1456).
(Swetha, S., & Sivakumar, P. 2021) Swetha, S., & Sivakumar, P. 2021. SSLA Based Traffic
Sign and Lane Detection for Autonomous cars. In 2021 International Conference on
Artificial Intelligence and Smart Systems (ICAIS) (pp. 766–771).
(Jayan, J., & Srinivasan, G. 2019) Jayan, J., & Srinivasan, G. 2019. AUTOSAR Based Dual
Core Partitioning for Power Train Application of BMS. In 2019 IEEE International
Conference on Intelligent Techniques in Control, Optimization and Signal Processing
(INCOS) (pp. 1–6).
(Sivakumar, P., Devi, R. S., Lakshmi, A 2020) Sivakumar, P., Devi, R. S., Lakshmi, A. N.,
VinothKumar, B., & Vinod, B. 2020. Automotive Grade Linux Software Architecture
for Automotive Infotainment System. In 2020 International Conference on Inventive
Computation Technologies (ICICT) (pp. 391–395).
(Soltani, M., & Knauss, E. 2015) Soltani, M., & Knauss, E. 2015. Challenges of Requirements
Engineering in AUTOSAR Ecosystems. In 2015 IEEE 23rd International Requirements
Engineering Conference (RE) (pp. 294–295).
(Dafang, W., Shiqiang, L., Bo, H. 2010) Dafang, W., Shiqiang, L., Bo, H., Guifan, Z., &
Jiuyang, Z. 2010. Communication Mechanisms on the Virtual Functional Bus of
AUTOSAR. In 2010 International Conference on Intelligent Computation Technology
and Automation (Vol. 1, pp. 982–985).
(Sandhya, D. R., Sivakumar, P., & Balaji, R. 2019) Sandhya Devi R.S., Sivakumar P., Balaji R.
2019. AUTOSAR Architecture Based Kernel Development for Automotive Application.
In: Hemanth J., Fernando X., Lafata P., Baig Z. (eds) International Conference on
Intelligent Data Communication Technologies and Internet of Things (ICICI) 2018.
ICICI 2018. Lecture Notes on Data Engineering and Communications Technologies,
vol 26. Springer, Cham.
 2 Use of Communication
Protocols in Automotive
Software Development
Process
R. S. Sandhya Devi
Department of EEE, Kumaraguru College of Technology,
Coimbatore, India

P. Sivakumar
Department of EEE, PSG College of Technology,
Coimbatore, India

B. Vinoth Kumar
Department of IT, PSG College of Technology,
Coimbatore, India

A. D. Buvanesswaran
PSG College of Technology, Peelamedu, India

CONTENTS
2.1 Communication Protocol................................................................................. 18
2.1.1 Need for Communication Protocol in Automotive
Software Development......................................................................... 18
2.2 Automotive Systems........................................................................................ 19
2.2.1 History of Automotive Inventions....................................................... 19
2.3 Automotive Communication Requirements....................................................20
2.4 Typical Subsystem Modules............................................................................ 21
2.5 Automotive Communication Technologies..................................................... 22
2.5.1 Wired Technologies............................................................................. 22
2.5.2 Control Area Network (CAN)............................................................. 22
2.5.3 Local Interconnect Network (LIN).....................................................24
2.5.4 MOST..................................................................................................24
2.5.4.1 Function Blocks (F Blocks)..................................................24
2.5.5 Flexray.................................................................................................25
2.5.6 Byteflight.............................................................................................25

DOI: 10.1201/9781003269908-2 17
18 Software Engineering for Automotive Systems

2.5.7 Other Technologies..............................................................................25

2.5.8 An Example Automotive System.........................................................26
2.6 Wireless Technologies..................................................................................... 27
2.6.1 ZigBee................................................................................................. 27
2.6.2 Bluetooth..............................................................................................28
2.6.3 Other Technologies..............................................................................28
2.7 Conclusion.......................................................................................................28
References................................................................................................................. 29

2.1 COMMUNICATION PROTOCOL

In general, communication protocols are used to transfer information from one
entity to other or from one to many which are connection together in a common
network. This information is transferred in a well-defined format based on the pro-
tocol used. This information is not transferred just like that. We have well-defined
formats starting from encryption till error recovery methods. Communication takes
place between two nodes with a pre-defined format which two devices should be
able to understand. Each message should carry a particular meaning whether it
is an information or command, and the same should be implicitly decoded by the
receiver. This response by the receiver should be as the one intended by the sender.
Communication protocols must be common and should be agreed by the stakehold-
ers involved in the communication.

2.1.1 Need for Communication Protocol in Automotive

Software Development
Automotive systems need networking to deal with the tedious architecture which
connect various parts together. Almost all the car manufacturers get the components
needed for their car from other common companies which agreed to supply the com-
ponents for many OEMs as a common architecture (Rappl, M et al 2002). Recent
inventions like ABS, airbag deployment module need interaction from various parts
of the car, which is possible only by networking. We have shifted from mechani-
cal interactions to X-by-wire technologies. The concept of technology replacement
should happen only when the latter is more reliable than the former. Starting from
sophistication for the passengers till dealing with the exhaust norms laid by the
Government, everything needs communication. Also, we cannot have a common
networking architecture as different applications need different types of communi-
cation as we are dealing with real-time systems.
An automotive system consists of many electronic control units (ECUs) which
work together or sometimes independently. Depending on the OEMs an automotive
system consists of minimum one ECU to a maximum 70 ECUs. This adds more
complexity to the system, particularly in networking part. In order to overcome this
complexity, several OEMs have come together to agree upon a common standard
architecture for automotive systems, which is AUTOSAR and communication proto-
cols like Flex ray (Sandhya, D. R., Sivakumar, P., & Balaji, R. 2019). In contrary to
normal braking and steering using mechanical parts, the X-by-wire technology has
Use of Communication Protocols in Automotive Software Development 19

used several actuators and sensors to replace the mechanical system. For the commu-
nication between the actuator and sensor components, we go for standard protocol.
If we take an automotive system, the requirement starts from the application we
use and criticality of that application. This decides how much importance we can
give for designing the network. If we divide the automotive system based on the
application and purpose, we can go with chassis, power train, body electronics, and
infotainment. These subsystems have different networking needs and this has to be
addressed with low latency. Another important thing is that, these networks have to
work easily together; there should be compatibility between them. Automotive sys-
tems are hard real-time systems, so error is not acceptable. And also, a car manufac-
tured today with the existing technologies should be flexible enough to update with
the new inventions, as a car runs for a minimum of ten years on road. Ten years is
an ample time for inventions. When an automotive system using minimum networks
to solve various requirements is appreciable as it reduces complexity and time. In
order to reduce this complexity, we have to go for a common networking topology.
These networks should support future plug-ins, less time requirement and support
“Network in Networks” (Muller, C., & Valle, M. 2011).

2.2 AUTOMOTIVE SYSTEMS

As explained earlier, an automotive system consists of chassis, power train, body
electronics, and infotainment in a broader sense. These have to be interconnected
using sensors and actuators to work together. This subsystem is not a one-day
invention; it is evolved over time, so needs a network of that kind.

2.2.1 History of Automotive Inventions

In the beginning, all the automotive components are connected by hydraulics and
mechanical connections. As time goes on, these were replaced by wires and cables
for error-free and comfort operations. This transformation is done step by step.
Today almost all automotive subsystems depend on electronics, so here we
introduced the concept of bus for hassle-free communication. When bus comes
into picture, we can utilize the concept of networking among all the dependent
components. Advancement towards this is fieldbus which is used for transferring
messages from one point to another. This field bus carries information to from an
ECU. As of today, almost all the automotive communication takes place through this
fieldbus (Chávez, M. L. 2006). In fieldbus, we have to take care of latency, errors,
security, etc. The advancement in electronics made the communication between the
ECUs, actuators, and sensors easier.
Initially, the OEMs themselves designed the fieldbus for their own dedicated pur-
pose, but as time goes on this R&D in this communication and maintenance took
them more time for taking the product to the market, so they went to the subcon-
tractors who has standardized concepts among OEMs and get it from them. Here,
OEMs just need to plug and play. As more OEMs are getting these done by sub-
contractors, standardization was done. In the beginning of 90s control area network
(CAN) was introduced, which is a standardized protocol developed by Bosch. After
20 Software Engineering for Automotive Systems

that, CAN became more popular, but CAN has used only two layers in OSI model,
so there were several advancements in CAN like Device Net, CAN Kingdom, and
CANopen. These protocols used higher layers of OSI model which gives easy main-
tenances and usability.
As the need pushed them to move form hydraulics and mechanical components to
electronic control, they were in need of high-speed bus system. After several rounds
of research and implementation in cars, they came with the system called “X-by-
wire” system. Reasons for moving from hydraulics to electronics are many, but the
most important one will be cost and maintenance of these systems and also advance-
ment needs completely new implementation. Another reason is recycling of heavy
hydraulic components are tedious.

2.3 AUTOMOTIVE COMMUNICATION REQUIREMENTS

Automotive communication requirements depend on the features with which the
network is associated with. In general, we can classify them as Security, flexibility,
bandwidth, determinism, and fault tolerance.
Security—Automotive system nowadays has recent technologies such as engine
control, driver assistance, braking mechanism, etc. These are controlled by software.
The cars nowadays have Wi-Fi connectivity for communication with the outside
world mainly for infotainment. Data is transferred to and from cloud. There is pos-
sibility of hacking the bus system and injecting fault codes. This results in serious
issues pertaining to the passengers.
Flexibility—Automotive subsystems are implemented based on their critical-
ity as discussed before. Based on this, a subsystem can be event triggered or time
triggered. For example, airbag deployment module is event triggered; airbag has to
deploy only when there is an impact. On the other hand, most warning systems are
time triggered. So, a communication protocol has to be flexible enough to accom-
modate this. Also, we have several mechanisms like bus arbitration, etc.
Bandwidth—Bandwidth, in general, refers to amount of data transmitted in a
bus in a given amount of time. When we take automotive system in specific, the data
need to be accurate and for an ECU it has to transmit and receive data to and from all
the nodes connected to the ECU, so here the bandwidth need to more. For example,
if we take antilock braking system (ABS), for an ABS to work properly, it should get
data from several sensors such as engine speed, vehicle velocity, etc. So, these data
will be transmitted simultaneously in a single ECU. So, the bus system should be
capable enough to accommodate more data at the same time.
Determinism—Automotive communication system should be deterministic,
there should be correct reception of messages. The messages should be sent and
received in a predicted amount of time. For periodic systems to work, data has to be
transmitted in the defined time interval else the system might go wrong. As men-
tioned earlier, in automotive system, we are dealing with many hard real-time sys-
tems, so determinism is a key factor for these systems to work properly (Sivakumar,
P. et al 2015).
Fault tolerance—In automotive system, we have many sensors associated with
hardware. Hardware components are susceptible to wear and tear. So, they might go
Use of Communication Protocols in Automotive Software Development 21

faulty at any time, especially in unpredicted situations. Correspondingly, the sensor

data goes wrong, which results in error in communication. These errors in communi-
cation should be predicted in advance and response should be provided, else the signal
goes corrupted. Also, the signal might get lost due to various physical factors; in this
situation also, some decision has to be taken, so the system should be fault tolerant.

2.4 TYPICAL SUBSYSTEM MODULES

In automotive system, networking is dependent on many modules; in a broader sense,
we have classified them as eight subsystem modules. They are:
Chassis subsystems come under vehicle active safety. We have two subsystems
here, electronic stability program (ESP) and vehicle dynamics control (VDC), this
is used to assist the driver in terms of dynamics of the car (Devi, R. S., Sivakumar,
P., & Sukanya, M. 2018). Engine ECU does this part. To overcome the possibility
of over steering, under steering, skidding, we have these systems. ABS also comes
under this, to prevent the locking of wheel while applying the brake at high velocity,
ABS need feedback communication as it needs the wheel speed for every cycle.
Airbag deployment module comes under passive safety system. Airbag deploy-
ment module is a hard real-time system. When a crash occurs, airbag has to be
deployed in minimum time, in order to prevent the passenger from hitting in the front
(Liebel, G 2018). Here from the time of impact, various step by step processes have to
be carried out before deployment. First seatbelt status should be checked, then seat-
belt pretensioners should be activated, after that only airbag has to be deployed. This
has to happen in order; means the communication to and from the airbag deployment
module has to be in such a way so that airbag will be deployed successfully.
Powertrain systems include the combustion of the fuel to produce power, till the
power reaches the wheel. This path needs communication at a greater co-ordination.
There should not be any loss as such. From the flywheel to the differential thorough
the gear box, there should be hassle-free transfer of power. This involves co-ordination
in injector timing, cam timings, exhaust gas recirculation, etc.
Body electronics does not come under safety, critical system. Seat belt adjustment,
wiper control, headlight control, window control are some of the human-machine inter-
face (HMI) which are soft real-time systems (Sivakumar, P et al 2016). So, networking
in these areas can be cost-effective, unless importance is given to it for sophistication.
However, automation in body electronics requires some dedicated network.
X-by-wire technology, as already explained, is the concept of replacing hydrau-
lics and mechanical components with computational electronics. So here, networking
is necessary. We have steer-by-wire, shift-by-wire, brake-by-wire, throttle-by-wire.
These are the subsystems which need dedicated communication to work efficiently.
Infotainment systems include music player, speakers, voice control, games etc.
These are not safety critical systems, so communication in these systems need not be
worried about in terms of fault tolerance or latency.
Telematics includes connecting the vehicle to the external world. This includes
GPS, traffic management, vehicle communication, etc. These systems need secure
communication as they are prone to attack from the outsiders. There are many tech-
nologies for secure communication with the Internet.
22 Software Engineering for Automotive Systems

Advanced driver assistance system (ADAS) assists the driver in driving and
parking functions. This is the base for autonomous driving field (Xu, Y.N. et al 2008)
(Swetha, S., & Sivakumar, P. 2021). This is done with the help of sensors and cameras
positioned at the various points in the vehicle. Some if its features include lane
departure warning, break assistance, emergency braking, etc. (Broy, J., & Muller-
Glaser, K. D. 2007). To be specific, ADAS needs proper communication only, from
the sensor to the system, from the system to the driver.
All the above-mentioned systems come under driving systems, which is needed
in a car to work. Another important system is on board diagnostics (OBD). OBD is
a self-diagnostic technology, where a car records the error and stores it as a specific
code related to the error. This we call it as diagnostic fault codes (DFC). These DFCs
are retrieved by the technician when the vehicle is taken for service. Reaching each
subsystem and debugging is a time consuming and tedious job for the technicians.
OBD also needs communication network from almost all the subsystems in the car,
to record the fault codes accurately.

2.5 AUTOMOTIVE COMMUNICATION TECHNOLOGIES

We have various automotive technologies used for the communication needs which
are mentioned above. Starting from the ancient technologies till the current trend,
some of them will be discussed in this section

2.5.1 Wired Technologies

Automotive manufacturers are using various technologies for communication.
Some of the most commonly used ones are CAN, LIN, MOST, Flexray. We will
look into these in detail and will see a brief of other technologies.

2.5.2 Control Area Network (CAN)

Robert Bosch developed CAN in 1985 for in-vehicle communication (Robert Bosch
Gmbh 2013). The development is a result of series of research in areas of automotive,
since the networks in car starts increasing due to increase in technologies. At first,
there are direct wire connections between components so complexity was less. But
as the functionalities increase, direct wire connection is not possible as the connec-
tion becomes bulkier and complex for operations and also debugging typical net-
work without CAN and With CAN as shown in Figure 2.1. In order to overcome this,
Bosch developed CAN.
CAN Benefits: CAN offers a cost-effective, durable network which enables many
CAN devices to connect with each other. The use of this is that every device in the
system can have single CAN interface better than analogue and digital inputs to
ECUs. In cars, this reduces overall cost and weight. Each message has a priority, in
case if two attempt to send messages at the same time, the one with the higher prior-
ity is sent and the one with the lower priority is delayed.
Each one of the devices have CAN controller chip on the network and is therefore
intelligent. All the computer devices see all the set messages.
Use of Communication Protocols in Automotive Software Development 23

Without CAN With CAN

I/O I/O

ECU ECU

device
device

FIGURE 2.1 Control area network. (National Instrument white paper. 2020)

To carry out error testing on each frame’s contents, the CAN specification con-
tains a cyclic redundancy code (CRC). Both node frames with errors and an error
frame may be transmitted to indicate the error in the network. The controller differ-
entiates between global and local errors, and incase more errors arise, corresponding
nodes stop sending errors or they get themselves disconnected (Wittmann, R., &
Zitterbart, M. 2000).
CAN Physical Layers: CAN has multiple distinct physical layers that can be
used. Some elements of the CAN network are defined by these physical layers, such
as transmission rate, signaling models, cable properties, baud rate, etc.
The physical layers that are widely used are discussed below:
Low-Speed/Fault-Tolerant CAN Hardware: Normally, CAN networks are often
designed with two wires, can communicate with devices at speeds up to 125 kbit/s,
and provide fault-tolerant transceivers. Other names include CAN B and ISO 11898-3
for low-speed/fault-tolerant CAN. Comfort devices include traditional low-speed/
fault-tolerant devices in a car.
High-Speed/FD CAN: The popular physical layer by far is the high-speed CAN.
With two wires, high-speed CAN networks are implemented and enable communi-
cation at transfer rates of up to 1 Mbit/s (Di Natale 2012). Other high-speed CAN
names include CAN C and 118982 ISO.
Software-Selectable CAN Hardware: With National Instruments CAN hard-
ware products, we can build CAN network either of the onboard transceivers (high-
speed, low-speed/fault-tolerant, or single-wire CAN) to use the software-selectable
CAN modules. Multiple transceiver modules will be a better solution for applications
that use a wide range of communication protocols (Johansson, K. H., Törngren, M.,
& Nielsen, L. 2005).
Single-Wire CAN Hardware: Communication speed can be up to 33.3 kbit/s
(88.3 kbit/s in high-speed mode) in single wire CAN communication networks.
Other names include SAE-J2411, CAN A, and GMLAN for single-wire CAN.
Working of CAN Communication: CAN networks do not have any master for
controlling the communication. Instead, each node can write CAN frame into the
24 Software Engineering for Automotive Systems

network, after checking whether the bus is busy. While writing into the network, no
address of the receiver is included in the frame. Alternatively, an arbitration ID is
included, which will be read by all the CAN nodes. These nodes will decide whether
to accept the frame, based on the arbitration ID (Sivakumar, P., Vinod, B., Devi,
R. S. 2015) (Paul et al 2016).

2.5.3 Local Interconnect Network (LIN)

LIN Topology and Behavior: LIN bus is constituted by a single master device and
multiple slave devices. Node capability file defines each node’s behavior. A device
generator parses the LDF to automatically generate the specified behavior within the
desired nodes. The master node master task begins transmitting headers to the bus at
this stage, and all the cluster slave tasks (including the master node’s own slave task)
react, as defined in the LDF.
LIN Error Detection and Confinement: The LIN 2.0 specification notes that
the slave tasks can manage error detection and that there is no need for error moni-
toring by the master task. The LIN 2.0 specification does not require the handling
within one LIN frame of multiple errors or the use of error counters. Upon encoun-
tering the first error in a frame, the slave task aborts frame processing before the
next break-sync sequence (transmitted by the master in the next header) is observed.
If the log bus error attribute is set to true, the read queue records a bus error frame.

2.5.4 MOST
For distinct functions, a MOST network must have a range of masters. Masters may
be housed in the same unit.
Timing Master: Controls network timing and, therefore, synchronization
between devices. Network master sets up the network and assigns system addresses.
Connection master sets up synchronous channels of communication between devices.

Power master
Control power supplies
Power-up and
shut down handles

A MOST system consists of three parts. Network Services Physical Interface—

These services are managed by a network interface controller (NIC). Modern NICs
have a processor built in and are called intelligent NICs, INICs.

2.5.4.1 Function Blocks (F Blocks)

These take care of the services that Function Blocks (FBlocks) can provide to the
system. A MOST system is not connected to a bus in the common sense. It has
an in port and out port and passes the information from the in port to the out
port. FBlocks can have functions with two different targets. The MOST
t(tk) FB locks application can be of three types. Controllers and slaves con-
trol one or more F Blocks. The MOST framework –HMIs-Human Computer
Use of Communication Protocols in Automotive Software Development 25

Interface-Used for user-device interaction. Through the F blocks, communication

between devices takes place. Without the sender understanding the address of the
receiving F block, the communication can take place. In the sending device, this
is achieved by so-called shadows. If the device includes more than one receiving
FBlock of the same kind, the connection will be much more complicated and the
device will have to handle the transfer and addressing of the NIC.

2.5.5 Flexray
BMW and Daimler-Chrysler after examination found that the existing technologies
will not support the automobile industry for future development in technologies espe-
cially X-by-wire systems (Mane, S. P., Sonavane, S. S., & Shingare, P. P. 2011). So, they
found that Flexray offers a solution for implementing X-by-wire systems by removing
some of the fieldbuses currently in use, thus, decreasing the overall network density
(Poledna S. 2001). Basically, today all car manufacturers joined this consortium, and
in mid-2004, the protocol specification was made public. In future automotive sys-
tems, FlexRay is used in ECU communication which need faster data exchange.

2.5.6 Byteflight
Byteflight was introduced in 1996 by BMW, and then further developed by BMW,
ELMOS, Infineon, Motorola, and Tyco EC. Safety-critical systems need more band-
width, which may now be satisfied by CAN but not in the future. So, Byteflight provides
a solution for this. ABS is one of the applications. When Byteflight was developed,
the key requirements were versatility, increased bandwidth than CAN. Byteflight sup-
ports network speeds of up to 10 MBps. For X-by-wire systems, Byteflight is a nomi-
nee. It has, however, been expanded to be part of the protocol of FlexRay.

2.5.7 Other Technologies
CAN, LIN, and Byteflight are most commonly applied in data exchange used for
chassis, power train, air bag, and electronics for physics and remedies, and diagnos-
tics. These are the first auto-rationale networking implementations in history, but
many innovations have been used over the years. Some were recurrent, while others
were eventually removed.
The Distributed Systems Interface, a master/slave network with verbal exchange
rates of up to 150 Kbps, used for security-related applications.
Safe-by-Wire is a master/slave network used for airbag control. Safe-by-wire has
elements taken from CAN and 150 Kbps conversation rates are supported. Since
CAN and LIN are no longer considered secure enough for airbag control, this verbal
exchange protocol was designed and developed by the Sound-by-Wire Consortium.
Motorola Interconnect (MI) In the experience that it is a simple low-fee master/
slave network specially designed for smart sensors, MI is comparable to LIN. However,
in today’s car systems, LIN is closed to being the world general.
Initially, the combination of computing devices with multimedia gadgets was the
position of multimedia and infotainment.
26 Software Engineering for Automotive Systems

Mobile Multimedia Connection (MML Bus) by Delphi Automotive Systems’.

It is providing 100 Mbps communication and plug-and-play feature of the master/
slave optic network.
IDB-1394 (Automotive Firewire) was initially used to connect PC computers,
but also to try to enter the automotive industry.
Domestic Digital Bus (D2B) via the Optical Chip Consortium. It is a group of
ring/star optics providing up to 20 Mbps of communication. In some Mercedes-Benz
models, D2B is included.
USB as Firewire, originally used in the PC market now trying to reach to the
automotive market.

2.5.8 An Example Automotive System

Communications are split into three categories: (1) powertrain and chassis, (2) body
electronics, and (3) infotainment. The network infrastructure of Volvo XC90 as
shown in Figure 2.2, it consists of nearly 40 control units, and the CAN occupies the
major part which is used for interconnecting these ECUs. The Different ECUs used
in each blocks as shown in Table 2.1.

FIGURE 2.2 Network infrastructure of Volvo XC90. (Nolte, T., Hansson, H., & Bello,
L. L. 2005)
Use of Communication Protocols in Automotive Software Development 27

TABLE 2.1
The Different ECU used in Volvo XC90

Block Powertrain and Chassis Block Infotainment

TCM Transmission control module ICM Infotainment control module
ECM Engine control module Block Body electronics
BCM Brake control module DDM Driver door module
BSC Body sensor cluster REM Rear electronic module
SAS Steering angle sensor PDM Passenger door module
SUM Suspension module CCM Climate control module
DEM Differential electronic Module ICM Infotainment control module
Block Infotainment UEM Upper electronic module
AUD Audio module DIM Driver information module
MP1 Media player 1 AEM Auxiliary electronic module
MP2 Media player 2 SRS P Supplementary restraint system
PHM Phone module PSM Passenger seat module
MMM Multimedia module SWM Steering wheel module
SUB Subwoofer CEM Central electronic module
ATM Antenna tuner module

Source: Nolte, T., Hansson, H., & Bello, L. L. (2005).

There are many cars which uses 100 ECUs in total. It is becoming more and more
difficult to incorporate these subsystems into the communication networks. Volvo
uses the Volcano definition in the case of the XC90. It is also possible to perform a
timings analysis of the method by using the Volcano instruments.

2.6 WIRELESS TECHNOLOGIES

For intra-vehicle and inter-vehicle communication, there are many communication
protocols that can be used for various applications. Extra- and extra-transportable
devices, such as cell phones, transportable GSM devices and laptop computer sys-
tems, may want to make the most of the vehicle communication when looking at
in-vehicle communications. Also, some new roles will leverage the possibility of
inter-vehicle communications, e.g., vehicle-to -vehicle and vehicle-to-roadside
communications.

2.6.1 ZigBee
The new low-cost and low-power wireless PAN standard is ZigBee (IEEE 802.15.4)
designed for applications like sensor and controls. Given the number of proprietary
systems with low data rates designed to meet the above specifications, there were
no criteria that fulfilled them. In addition, the use of such devices has posed major
interoperability concerns that ZigBee technology addresses, offering solution for
sensor and control applications. In December 2004, the first ZigBees specification
for wireless data communications was ratified by the ZigBee Alliance (with over
28 Software Engineering for Automotive Systems

120 company members). ZigBee offers network speeds of up to 250 Kbps and is
intended to be widely used for control and monitoring purposes in the automotive
industry as a sensor network.

2.6.2 Bluetooth
Bluetooth (IEEE 802.15.1) officially offers up to 3 Mbps (Bluetoothv2.0) network
speeds. Bluetooth technology offers low-power, low-cost, short-range communication.
As a potential automotive wireless networking technology, the automotive envi-
ronment is also very enticing.
The Bluetooth Special Interest Group (SIG) founded the Car Working Group in
December 1999 in response to this interest. The hands-free profile was the first of
many requirements planned from the Car Working Group for the application stage
(Kovačević, J., Kaprocki, N., & Popović, A. 2019).
The Bluetooth SIG set out a three-year plan for potential bluetooth enhancements in
November 2004. Quality of Service, security, power consumption, multicast capabili-
ties, and privacy improvements are prioritized targets. It is expected that long-range
performance improvements will increase the range of bluetooth-enabled sensors.

2.6.3 Other Technologies
Wi-Fi stands for wireless fidelity and for every form of IEEE 802.11 network is the
general term. Wi-Fi is used, for example, by the Car2Car Consortium, a non-profit
organization initiated by European vehicle manufacturers, for inter-vehicle commu-
nications (Devi, R. S., Sivakumar, P., & Balaji, R. 2018) (Sivakumar P. et al 2020).
Advanced drive assistance to minimize the number of incidents, decentralized float-
ing car data to enhance local traffic flow and performance, and comfort and business
applications for user communications and information services to drive and pas-
sengers are applications here. For example, the European network-on-wheels (NoW)
project is a research project working in this field.
UWB (IEEE802.15.3a), or ultrawide band, has become rival to the IEEE 802.11
standards. UWB supports high bandwidth communication. Collision detection sys-
tems and suspension systems reacting to road conditions are other possible vehicle
applications that could be assisted by UWB. However, as UWB is a young technol-
ogy, these applications are not yet accessible.

2.7 CONCLUSION
We have discussed about the trends in technologies of automotive communication,
the recognition of typical requirements and novel vehicle technology specifications
and addressing to what extent networking is available and upcoming technologies
are capable of satisfying such demands. The next steps in automotive communica-
tions were discussed, focusing on X-by-wire systems and applications for wireless
communications. Today, one of the greater problems is interconnecting potentially
modern automotive architecture networks that are heterogeneous. This will be
answered by implementing standardized middleware technologies.
Use of Communication Protocols in Automotive Software Development 29

REFERENCES
(Broy, J., & Muller-Glaser, K. D. 2007) Broy, J., & Muller-Glaser, K. D. 2007. The Impact
of Time-Triggered Communication in Automotive Embedded Systems. In 2007
International Symposium on Industrial Embedded Systems (pp. 353–356).
(Chávez, M. L. 2006) Chávez, M. L. 2006. Fieldbus Systems and Their Applications 2005.
In Proceedings Volume from the 6th IFAC International Conference.
(Devi, R. S., Sivakumar, P., & Balaji, R. 2018) Devi, R. S., Sivakumar, P., & Balaji, R. 2018.
AUTOSAR Architecture Based Kernel Development for Automotive Application.
In International Conference on Intelligent Data Communication Technologies and
Internet of Things (pp. 911–919).
(Devi, R. S., Sivakumar, P., & Sukanya, M. 2018) Devi, R. S., Sivakumar, P., & Sukanya,
M. (2018). Offline analysis of sensor can protocol logs without can/vector tool usage.
International Journal of Innovative Technology and Exploring Engineering, 8(2S2),
pp. 225–229
(Di Natale, M., Zeng, H., Giusto, P 2012) Di Natale, M., Zeng, H., Giusto, P., & Ghosal, A.
2012. Understanding and Using the Controller Area Network Communication Protocol:
Theory and Practice. Springer Science & Business Media.
(Johansson, K. H., Törngren, M., & Nielsen, L. 2005) Johansson, K. H., Törngren, M., &
Nielsen, L. 2005. Vehicle applications of controller area network. In Handbook of
Networked and Embedded Control Systems (pp. 741–765). Birkhäuser, Boston.
(Kovačević, J., Kaprocki, N., & Popović, A. 2019) Kovačević, J., Kaprocki, N., & Popović,
A. 2019. Review of Automotive Audio Technologies: Immersive Audio Case Study.
In 2019 Zooming Innovation in Consumer Technologies Conference (ZINC)
(pp. 98–99).
(Liebel, G., Tichy, M., Knauss, E. 2018) Liebel, G., Tichy, M., Knauss, E., Oscar Ljungkrantz
& Gerald Stieglbauer. 2018. Organisation and communication problems in automotive
requirements engineering. Requirements Engineering, 23, 145–167.
(Mane, S. P., Sonavane, S. S., & Shingare, P. P. 2011) Mane, S. P., Sonavane, S. S., & Shingare,
P. P. 2011. A Review on Steer-by-Wire System using Flexray. In 2011 2nd International
Conference on Wireless Communication, Vehicular Technology, Information Theory
and Aerospace & Electronic Systems Technology (Wireless VITAE) (pp. 1–4).
(Muller, C., & Valle, M. 2011) Muller, C., & Valle, M. 2011. Design and Simulation of
Automotive Communication Networks: the Challenges. e & i Elektrotechnik und
Informationstechnik, 128(6), 228–233.
(Nolte, T., Hansson, H., & Bello, L. L. 2005) Nolte, T., Hansson, H., & Bello, L. L. 2005.
Automotive Communications-past, Current and Future. In 2005 IEEE Conference on
Emerging Technologies and Factory Automation, Vol. 1, pp. 8–992.
(Paul, A., Chilamkurti, N., Daniel, A. 2016) Paul, A., Chilamkurti, N., Daniel, A., &
Rho, S. 2016. Intelligent Vehicular Networks and Communications: Fundamentals,
Architectures and Solutions. Elsevier.
(Poledna, S., Ettlmayr, W., & Novak, M. 2001) Poledna, S., Ettlmayr, W., & Novak, M. 2001.
Communication bus for automotive applications. In Proceedings of the 27th European
Solid-State Circuits Conference (pp. 482–485).
(Rappl, M., Braun, P., von der Beeck, M. 2002) Rappl, M., Braun, P., von der Beeck, M.,
& Schröder, C. 2002. Automotive software development: A model-based approach
(No. 2002-01-0875). SAE Technical Paper.
(Robert Bosch Gmbh 2013) Robert Bosch Gmbh. 2013. Bosch Automotive Electrics and
Automotive Electronics. In Systems and Components, Networking and Hybrid Drive,
5th edition. Springer Vieweg.
(Sandhya, D. R., Sivakumar, P., & Balaji, R. 2019) Sandhya Devi R.S., Sivakumar P.,
Balaji R. 2019. AUTOSAR Architecture Based Kernel Development for Automotive
Application. In Hemanth J., Fernando X., Lafata P., Baig Z. (eds) International
30 Software Engineering for Automotive Systems

Conference on Intelligent Data Communication Technologies and Internet of Things

(ICICI) 2018. Lecture Notes on Data Engineering and Communications Technologies,
vol 26. Springer, Cham.
(Sivakumar, P., Devi, R. S., Lakshmi, A 2020) Sivakumar, P., Devi, R. S., Lakshmi, A. N.,
VinothKumar, B., & Vinod, B. 2020. Automotive Grade Linux Software Architecture
for Automotive Infotainment System. In 2020 International Conference on Inventive
Computation Technologies (ICICT) (pp. 391–395).
(Sivakumar, P., Vinod, B., Devi, R. S. 2015) Sivakumar, P., Vinod, B., Devi, R. S., & Rajkumar,
E. J. 2015. Real-time task scheduling for distributed embedded system using MATLAB
toolboxes. Indian Journal of Science and Technology, 8(15), 1–7.
(Sivakumar, P., Vinod, B., Devi, R. S. 2016) Sivakumar, P., Vinod, B., Devi, R. S., & Divya,
R. S. (2016). Deployment of effective testing methodology in automotive software
development. Circuits and Systems, 7(9), 2568–2577.
(Swetha, S., & Sivakumar, P. 2021) Swetha, S., & Sivakumar, P. 2021. SSLA Based Traffic
Sign and Lane Detection for Autonomous cars. In 2021 International Conference on
Artificial Intelligence and Smart Systems (ICAIS) (pp. 766–771).
(Wittmann, R., & Zitterbart, M. 2000) Wittmann, R., & Zitterbart, M. 2000. Multicast
Communication: Protocols, Programming, & Applications. Elsevier.
(Xu, Y. N., Jang, I. G., Kim, Y. E 2008) Xu, Y. N., Jang, I. G., Kim, Y. E., Chung, J. G., &
Lee, S. C. 2008. Implementation of FlexRay Protocol with an Automotive Application.
In 2008 International SoC Design Conference (Vol. 2, pp. II-2–II-25).
(National Instrument White paper. 2020) Controller Area Network (CAN) Overview. National
Instrument White paper, 06, 2020. Available (https://www.ni.com/en-in/innovations/
white-papers/06/controller-area-network--can--overview.html)
 3 Bootloader Design
for Advanced Driver
Assistance System
R. S. Sandhya Devi
Department of EEE, Kumaraguru College of Technology,
Coimbatore, India

B. Vinoth kumar
Department of IT, PSG College of Technology,
Coimbatore, India

P. Sivakumar
Department of EEE, PSG College of Technology,
Coimbatore, India

A. Neeraja Lakshmi
Department of EEE, PSG College of Technology,
Coimbatore, India

R. Tripathy
Product Engineering Services, KPIT Technologies Ltd.,
Pune, India

CONTENTS
3.1 Introduction..................................................................................................... 32
3.2 Existing Systems.............................................................................................. 33
3.3 Proposed System: Unified Diagnostic Services (UDS)...................................34
3.4 Flash Bootloader.............................................................................................. 35
3.5 UDS-Based Bootloader................................................................................... 36
3.6 System Implementation: Basic Bootloader Stack............................................ 36
3.7 Application Software Flashing Using Bootloader........................................... 39
3.7.1 Hardware Requirements...................................................................... 39
3.8 Simulation........................................................................................................40
3.9 Secure ECU Software Update: Software Integrity.......................................... 41

DOI: 10.1201/9781003269908-3 31
32 Software Engineering for Automotive Systems

3.10 Automotive Virtualization............................................................................... 42

3.10.1 AGL Virtualization Concept............................................................... 42
3.11 Conclusion....................................................................................................... 43
References.................................................................................................................44

3.1 INTRODUCTION
Each electronic control unit (ECU) in an automobile is responsible for the execution
of a particular program. For instance, an ECU antilock braking system makes sure
brakes are not stuck during braking. The ABS software program in the ECU hard-
ware is capable of recording the vehicle speed as an input and is designed based on
this information to minimize the brake on the wheels.
Bootloader is the software algorithm which is performed during device boot.
Host of functionalities are provided by automotive ECUs (control units). Such
technologies and functionalities have become highly sophisticated and complex.
To the automotive original equipment manufacturers (OEMs) and suppliers, it has
become crucial to ensure that these software-driven control units are still working
in a secure and productive environment. This will only be done if the ECUs have
the current and patched version of the software and security updates inside the
car. Hence, the framework developed and ported on the MCU platform will also
be modified very regularly, either from a remote location or at the service station.
This task of initiating the ECU software upgrade was assigned to the bootloader
program, which occupies the ECU ROM.
When looking at a luxury vehicle, though, one can note that it has almost 100 mil-
lion lines of software code. But this is very huge compared to an aircraft, which has
only six million lines of code. Therefore, owing to these large amounts of electronic
code, the firmware upgrade of an automotive ECU is a repetitive activity.
A bootloader software is designed to automate this flash reprogramming process
and to handle the firmware upgrade. The bootloader program tests that the latest/
updated version of the ECU program is usable at the device boot-up. If yes, then
bootloader program installs and stores the newly installed firmware version before
booting the device. Post this, the device boot-up is executed and device now runs in
a fully protected environment on the latest version of the program.
At over 100 million lines of code in the total design, more than a conventional
operating system, autonomous cars can no longer be viewed as pure mechanical
devices. Increasingly, cars are linked and computer-like, with the potential to inter-
act with cell phones, provide car passengers with the current weather and traffic
alerts, and relay safety details to other automobiles and facilities surrounding them.
Vulnerabilities in vehicle communications result in four obstacles to vehicle safety
such as restricted access, restricted numerical capacity, volatile attack scenarios, and
threats and essential danger to the life of drivers or passengers.
The main objective of this chapter is to develop a bootloader software using uni-
fied diagnostic protocols. The technique has to be implemented using any of the com-
munication channel connecting the ECU. The bootloader should be able to provide
a secure ECU reprogramming every time whenever a software update is requested.
In order to mitigate the security treats faced by the connected vehicles, the software
Bootloader Design for Advanced Driver Assistance System 33

platform AGL has to be discussed. It should be able to provide a feasible update of

software and application in an ADAS system. Apart from AGL, other platforms and
their efficiency in terms of providing secure software update is detailed.

3.2 EXISTING SYSTEMS

An application to facilitate automotive remote update was developed (Zhang et al.,
2018). The authors have discussed the related technology of bootloader software. As
a means to upgrade the development software, the incremental change was brought
in. They also introduced a comprehensive application architecture that involves
memory model, state flow map, processes operating different applications, and appli-
cations frameworks. Generally, ECU programming began at first with the erasure of
the whole memory area. Instead, the entire new codes were written into the ECU
guide. The part of the codes that is modified is removed by itself and then revised.
The physical space in flash is removed, and full writing is finished. It would mini-
mize information fragmentations to maintain strong resource use. Using the gradual
upgrade approach will significantly minimize the size of the software update and
substantially reduce the installation period.
The steps needed to obtain a flash bootloader for an intelligent vehicle system
were discussed (Bogdan et al., 2017) and also offer insights into the performance of
using such an application. The methodology focused on the technology framework
JCP2011, while the used hardware is a dashboard instrument with a RENESAS-
produced microcontroller (3PD70F3537). The flash bootloader is an extension of
the diagnostic feature and takes control of the dashboard instrument device upgrade
using a unified diagnostic services (UDS) protocol. The diagnostic component of
the program is described by a series of resources to be identified, checked, and per-
formed by the device. The flash bootloader component of the diagnostic part accepts
a limited set of commands from the entire protocol. This approach benefits from the
sustainability point of view by reducing the need to travel to specialist centers to
upgrade apps and also by downloading updates eliminating software bugs. It leads
to more effective operation and smaller environmental and traffic effects.
Several cybersecurity challenges faced during the ECU update in vehicular
communications were discussed by Rewinia et al. (2020). A three-layer framework
(sensing, communication, and control) through which automotive security threats
can be better understood was proposed. The sensing framework consists of vehicle
dynamics and environmental sensors that are susceptible to attacks through eaves-
dropping, jamming, and spoofing. Attacks targeting the levels of sensing and com-
munication will spread upward and impact the functionality, which can undermine
the control layer’s stability. The paper argues for a need for modern technologies
to use systems of systems (SoS) approach to threats identification and mitigation.
These architectures will concentrate on protecting sensitive units with cryptographic
and noncrypto-based algorithms, registration, authentication procedures, and much
more, such as power train ECUs.
An open-source secure software updates for Linux-based IVI systems were devel-
oped (Arthur Taylor, 2016). Cybersecurity and vehicle recalls are two significant fac-
tors in the production of automobile tech. Over-the-air upgrades are essential to enable
34 Software Engineering for Automotive Systems

car and system vendors to reduce protection and service threats as software is applied
to automobile fleets, but there was no end-to-end open-source approach to handle
upgrades until recently. Advanced telematic systems (ATS) has been collaborating
with GENIVI and AGL in their development/reference networks to incorporate stable
app updates. The paper provides an analysis of current open source OTA solutions,
implemented the GENIVI SOTA open source solution, defined its design and security
features, and defined the incorporation of the OTA system into the GENIVI develop-
ment platform and the AGL framework.
Linux-based automotive security mechanisms could be used to make the connected
cars safer and more secure in the future. The idea of virtualization is explored to
establish the impression of several private subsystems or guest systems inside a single
host system (Foll and Bollo, 2016). Each virtualization framework has frameworks
for minimizing the usage of resources. Virtualization may be more or less complete,
based on the model selected. Every computer has in certain cases a private kernel,
with its own dedicated hardware resources. In other instances, virtual hosts share
nearly everything: a single kernel, file system, RAM, I/O device with very limited
separation, such as a private collection of libraries to curtail RAM or processor use.
Security hardening features based on ARM’s TrustZone technology for info-
tainment systems is proposed that ensures confidentiality and integrity of critical
applications (Maksym, 2018). In addition, a strategy is introduced that enables miti-
gating the effect of certain attacks on the internal network of the vehicle. TrustZone
is a hardware design, introduced with ARM processors on system-on-chip (SoC)
computers and offers a protection mechanism to combat several vulnerabilities in
embedded systems. TrustZone’s primary function is partitioning both hardware and
software resources into one of two worlds—safe, for protection subsystems and criti-
cal properties, and regular, for everything else. The planned research guarantees the
safe elements remain secure and are essential.
The APPSTACLE project is discussed that simplifies the production phase of
automotive systems by providing an accessible and safe software framework that
links a wide range of automobiles to the software through in-car and internet con-
nections (Pakanen et al., 2017). APPSTACLE project goal needs a wide spectrum
of skills from networking systems to software-based technologies and services. The
in-vehicle design tackles existing and lacking modules, utilities, protocols, APIs,
and layers of software needed for stable and safe incorporation of the Car2X in-car
framework. Direct cloud access standardization for in-car applications by a specific
Car2X gateway interface also introduces the need for the prototypical specific Car2X
gateway, which facilitates ECU wide remote access (e.g., through the gateway’s CAN
bus connectivity) to the cloud.

3.3 PROPOSED SYSTEM: UNIFIED DIAGNOSTIC SERVICES (UDS)

UDS is a diagnostic communication protocol (ISO 14229-1) in the vehicle electronics
of the ECU, as laid down in ISO 14229-1. This is built from ISO 14230-3 (KWP2000)
and ISO 15765-3 (Controller Area Network (DoCAN) Diagnostic Communication)
(ISO 15765-2). This communication protocol is used in almost every new ECU made
by OEM Tier 1 suppliers. The architecture of UDS protocol is shown in Figure 3.1.
Discovering Diverse Content Through
Random Scribd Documents
että voisitte löytää vanhempanne Cumberlannista, oli turha
otaksuma."

"Häh! Miksi?"

"Koska teidän äitinne on kuollut."

Drayton pudisti hetkeksi viinanhöyryt päästänsä ja osoitti

tavatonta mielenkiintoa.

"Sen turvakodin luettelo, johon hänet otettiin itsemurhayrityksen

jälkeen, sisältää ilmoituksen —"

"Mutta hän karkasi", keskeytti Drayton.

"Sisältää ilmoituksen, että hän karkasi ja pääsi turvaan — kuoli.

Hänen ruumiinsa saatiin joesta ylös, tunnettiin mainituksi henkilöksi
ja haudattiin hänen nimellänsä."

"Millä nimellä?" kysyi Drayton.

Hugh Ritsonin ilme muuttui äkkiä.

"Mitäs sillä on väliä", hän sanoi, "olen sen unohtanut."

"Todellako unohtanut?" epäili Drayton. "Eikö se olisi voinut olla

Ritson, häh?"

Hugh iski nyrkkinsä pöytään.

"Totisesti ei — hänen nimensä ei ollut Ritson."

Ääni suututti herra Draytonia Hän katsoi Hugh Ritsoniin ikäänkuin

sanoen, että tämä sai kiittää luojaansa, joka oli tehnyt hänen toisen
jalkansa hervottomaksi, niin että hän nilkutti.

Hugh Ritson tyynnytti häntä selittämällä, että jos hän oli utelias
tietämään, mikä hänen äitinsä nimi oli, hän kyllä voi sen saada
selville ja lisäsi: "Mitäpä nimi silloin hyödyttää, jos teidän äitinne
kerran on kuollut?"

"Se on totta", sanoi Drayton, joka nyt oli tyyntynyt ja alkoi tulla
vakuutetuksi, että hänen vaivannäkönsä oli ollut turha.

"Saatte olla varma, että teidän isänne, missä hän nyt lieneekin, on
aika lurjus", sanoi Hugh Ritson.

Drayton nousi jaloillensa ja kävi edestakaisin laahustavin askelin.

Äkkiä lensi eräs ajatus hänen mieleensä. "Se nainen, joka otettiin
ylös virrasta, saattoi olla joku toinenkin. Sellaisesta olen kyllä
kuullut."

"Mahdollista kyllä, mutta vaikka se olisi erehdyskin, ei se

kuitenkaan teitä hyödyttäisi." Tätä sanoessaan Hugh näytti
neuvottomalta, mutta Drayton ei sitä huomannut.

"Pah! Mitäpäs siitä?" sanoi Drayton ja päättäen olla enää

vaivaamatta aivojansa tällä asialla hän lähestyi viinapulloa ja joi vielä
puoli lasia. Heidän suhteensa muuttui nyt perin ystävälliseksi.

"Sanokaa minulle", pyysi Hugh, "mitä tapahtui Ghyllissä

maanantai-iltana?"

"Ghyllissä? Maanantaina? Se oli se ilta, jolloin satoi lunta. Mitä

tapahtui? Ei mitään."

"Mitä te siellä teitte?"

 "Halusin nähdä teidän äitiänne. Näin teidän veljenne eräänä
myöhäisenä iltana pappilan ovella. Näin teidät tulipalossa. Olittehan
tulipalossa? — tietysti. Seisoin kymmenen kyynärän päässä, kun se
nuori pukki, tallimies, palasi rattaineen taloon. Mitä syytä käyntiini?
Hittoko ne kaikki syyt tietää! Minä koputin eikä ketään kuulunut. En
tiedä, kuinka kauan seisoin ja palellutin jalkojani ovella. Sitten minä
näin valoa muutamasta ensimmäisen kerroksen huoneesta, mutta
minä menin ylös ja koputin. 'Sisään', sanoi joku. Minä menin sisään.
Harmaahapsinen vanhus nousi ylös. Mustassa puvussa ja
rukousnauha kaulassa, tiedättehän. Mutta ennenkuin minä ehdin
puhua mitään, hän pyörtyi kuin kana ja lyyhähti lattialle. Jumal'
avita, ellei se vanha tyttö pitänyt minua aaveena." Herra Drayton
nosti kulmiansa ja lisäsi: "Minä lähdin tieheni."

"Ja tullessanne te säikytitte käytävällä erästä nuorta naista, joka,

kuten minun äitinikin, luuli teitä minun veljekseni Pauliksi. No niin,
tämä nuori nainen on tänään mennyt naimisiin minun veljeni kanssa.
He ovat nyt matkalla Lontooseen. He aikovat jättää Englannin ensi
keskiviikkona, ja nyt he ovat päättäneet viettää ensi yön teidän
ravintolassanne."

Herra Draytonin kulmat kohosivat taaskin.

"Sitä tietenkin on sangen vaikea ymmärtää, mutta katsokaa", ja

Hugh Ritson antoi Bonnithornelta saamansa sähkösanoman
Draytonille. Tämä herra katseli ja käänteli sitä minuutin ajan sumein
ja hämmästynein silmin ja sitten kääntyi vieraaseensa saadakseen
selvitystä.

"Tämä nainen ei saa lähteä Englannista", sanoi Hugh.

 Drayton koetti kaikin voimin hallita tasapainoansa ja näyttää
hämmästyneeltä.

"Sieluni kautta te saatte minun vereni kiehumaan", hän sanoi.

"Mitä minun pitää tehdä saadakseni teidän kaksikymmentä
puntaanne? Puhukaa selvästi. Minä en ole lurjus, en. Minä olen
oikeutettu ravintoloitsija ja herrasmies —"

"Mitäkö on tehtävä? Teidän on vain lähetettävä se nainen takaisin

kotiin ensimmäisellä junalla."

Drayton alkoi nauraa.

"Kuten näette, ei ollut mitään pelästymisen syytä", sanoi Hugh

viattomasti hymyillen.

Draytonin nauru tuli äänekkääksi.

"Minun on toimitettava se nuori rouva pois uskottelemalla hänelle,

että olen hänen miehensä, vai?"

"Herra Drayton, te olette sukkela veitikka."

"Ja mitäs sanoo siihen oikea aviomies — eikö hänkin ole sukkela
veitikka?"

"Jättäkää hänet minulle. Hetken tultua älkää viivytelkö. Älkää

puhuko tarpeettomasti mitään. Käyttäkää tuota ulsteria, joka teillä
nyt on. Puhukaa niin vähän kuin mahdollista — eikä mitään muuta
kuin välttämätöntä. Viekää rouva vaunuun, joka odottaa tässä ovella,
ajakaa asemalle, ostakaa piletti Keswickiin, toimittakaa hänet junaan
viime hetkessä ja rientäkää sitten viivyttelemättä tiehenne. Yöjuna ei
koskaan pysähdy ennen Bedfordia."
 Drayton löntysti yli lattian ääneen nauraen. "He, he, he, kuinka,
kuinka — minun on jätettävä hänet asemalle, häh? Nuori raukka —
minulla ei ole sydäntä, ei ole voimaa olla niin raaka. Ei, ei, minä en
voi olla sellainen aviomies-roisto, he, he, voi, voi, ja vielä tyttöparan
hääpäivänä."

Hugh Ritson hypähti seisoalleen.

"Jos te menette tuumankaan pitemmälle kuin asemalle, saatte

katua sitä elämänne loppuun", hän kivahti iskien vielä kerran
nyrkkinsä pöytään.

Tämä teki Draytonin naurun ja hyväntuulen vieläkin

äänekkäämmäksi ja hän selitti, että olisi tarpeen tilata toinen
puolikas viinaa, joka huuhtoisi pahan halun pois hänen suustaan.

Sitten hänen naurunsa asettui.

"Katsokaa, te tahdotte saada minut tekemään työn, johon kykenee

vain yksi ainoa elävä olento. Ja mitä te tarjoatte siitä minulle?
Kaksikymmentä vaivaista puntaa. Pitäkää nekin", hän sanoi, "se ei
kävele, herra."

Tuli oli kokonaan riittynyt. Iloton huone oli melkein pimeä ja ilma
sakea savusta ja tukahduttavan ummehtunut vanhasta tupakan ja
viinan hajusta. Drayton napitti pitkän takkinsa kurkkuun asti.

"Minä olen myöhästynyt", hän sanoi, "hyvää yötä."

Lasten ääniä kuului kapakasta. Pienokaiset olivat matkalla kotiin.

"Hyvää yötä, neiti, ja kiitoksia paljon", sanoi naisääni.

 "Hyvää yötä, Mercy", huusivat lapset.

Drayton aikoi avata oven.

"Ajatelkaa tarkemmin", sanoi Hugh. "Teille ei ole siinä mitään

vaaraa.
Yksitoista ja neljäkymmentä viisi täsmälleen sen tulee tapahtua."
IV LUKU.

Kun Drayton meni ulos, asteli Hugh Ritson kapakkahuoneeseen.

Vieraat olivat menneet. Kapakan emäntä vain yksin hääräili
myymäpöytänsä takana. Vasemmalle menevä ovi oli nyt auki.

"Rouva Drayton", sanoi Hugh, "oletteko te koskaan ennen nähnyt

näitä kasvoja?"

Hän otti medaljongin taskustaan ja piti sitä auki vanhan vaimon

edessä.

"Herra hyvästi siunatkoon!" huudahti kapakan emäntä. "Sehän on

juuri hän itse — ihan ilmetty itsensä — paitsi tuota nunnan huntua."

"Onko tämä se nainen, joka asui teidän luonanne Pimlicossa —

Paulin äiti?"

"Totisesti, totisesti! Herra nähköön, on. Ja ajatelkaa, se nuori

armas raukka on nyt kuollut ja mennyt sinne. Siitä on nyt
kolmekymmentä vuotta, mutta se panee minut itkemään. Ja minun
mieheni — hänkin on mennyt. — Minun mieheni sanoi minulle:
'Martha', hän sanoi, 'Martha' —"
 Kapakan emännän livertelyn lopetti riemukas: "Hugh, Hugh!"

Mercy Fisher seisoi ovella silmät iloisesta hämmästyksestä auki

revähtäneinä ja rinta nousten ja laskien.

Sinä hetkenä onneton pikku raukka oli hyökännyt yli lattian Hughin
syliin, jossa vapisi kuin säikähtänyt lintu.

"Oi, minä tiesin, että tulisit — minä olin varma, että sinä tulisit",
hän sanoi kuivaten silmänsä, taas itkien ja kuivaten ne uudestaan ja
kohotti värisevät huulensa suudeltaviksi.

Hugh Ritson ei osoittanut vähintäkään tunteellisuutta.

Tyytymättömyyden varjo levisi ensin hänen kasvoilleen, mutta katosi
pian. Hän koetti näyttää ihastuneelta ja taivuttaen päänsä kosketti
kevyesti verettömiä huulia.

"Sinä näytät riutuneelta, pikku raukka", hän sanoi hiljaa. "Mikä

sinua vaivaa?"

"Ei mikään — ei mikään nyt, kun sinä olet tullut. Sinä vain olit
tulematta niin kauan, niin hirveän kauan."

Hugh koetti keksiä jonkun lohduttavan sanan.

"Mutta näethän, että minä pidän sanani, sinä tyttöhupakko", hän

sanoi ja hymyili nyökäten hänelle iloisesti päätänsä.

"Ja sinä olet vihdoinkin tullut minua katsomaan! Koko tämän

pitkän matkan katsomaan minua, pikku raukkaa?"

Raskas surumielisyys, joka tähän asti oli kuvastunut hänen

kasvoillaan, häipyi ja sijalle ilmestyi loistava hymy.
 "Täytyyhän tehdä jotakin sen hyväksi, joka on uskaltanut niin
paljon toisen vuoksi", virkkoi Hugh hieman naurahtaen.

"Ah!"

Kun ensimmäinen hämmästyksen puuska oli ohi, ei seuraavana

ilon hetkenä puhelahja kyennyt tunteita tulkitsemaan. Tytön kädet
kiertyivät Hughin kaulaan ja ääneti Mercy katseli hänen kasvojansa,
ja silmät kirkastuivat kirkastumistaan.

"Ja sinusta tuntui aika pitkältä ja ikävältä?" kysyi Hugh.

"Minulla ei ollut ketään, jonka kanssa olisin voinut, puhua", vastasi

Mercy teeskentelemättömästi.

"Ai, sinä kiittämätön pikku olento, olihan sinulla hyvä rouva

Drayton ja hänen poikansa ja kaikki sievät Hendonin pojat, jotka
tulevat tänne kapakkaan juomaan ja puhumaan monia hauskoja
asioita pienelle kapakkaneidille ja —"

"Ei se ole sitä! Minulla ei ollut ketään, joka olisi tuntenut sinut",
sanoi Mercy laskien äänensä kuiskaukseksi.

"Mutta menethän sinä joskus ulos — kylään — Lontooseen?" kysyi

Hugh.

"En, minä en milloinkaan mene ulos — en koskaan nyt."

"Ovatko sinun silmäsi sitten todellakin pahemmat?"

"Ei se ole minun silmäini vuoksi. Mutta sillä ei väliä. Oi, minä
tiesin, ettet sinä unohtaisi minua. Vain joskus iltaisin, kun hämärä
hiipi sisään ja minä istuin ihan yksin takan ääressä, minä ajattelin:
'Hän ei välitä minusta. Hän ei tule minua hakemaan.' Mutta se ei
ollut totta, eihän?"

"Kas, no ei, tietysti ei."

"Ja sitten kun lapset tulivat — tuon naapurin lapset — ja minä

panin niitä nukkumaan ja ne pikku lemmikit lukivat siunauksensa, ja
minä koetin myöskin rukoilla, niin silloin, silloin" — hän katsahti
arasti ympärilleen ja kuiskasi — "oli kuin joku olisi sanonut: 'Miksi
hän jättää minut yksin — olinhan minä niin onnellinen?'"

"Sinä olet sairas, pikku raukka, mutta sinä tulet vielä onnelliseksi
— olethan sinä onnellinen nyt, etkös olekin?" sanoi Hugh.

Tytön silmät, sumeat ja punaiset, kirkastuivat ja niistä loisti hellä

rakkaus, kun hän käänsi ne häneen, ja koko olemus kertoi
täydellisestä onnesta.

"Ah!" hän sanoi ja painoi kauniin päänsä hänen rintaansa vasten

"Mutta sinun olisi pitänyt kävellä — tehdä pitkiä, terveellisiä ja

onnellisia kävelymatkoja", puheli Hugh.

"Teinhän minä — kun ruusut kukkivat ja tuhatkaunot kukoistivat,

ja minä kokosin niistä monta sitä varten, että sinä tulisit, kokosin
metsäruusuja ja valkoruusuja, mutta sinä olit niin kauan tulematta,
ja ne kuihtuivat. Ja sitten minä en voinut niitä heittää pois, koska
ymmärräthän — ne olivat sinun — niinpä minä kuivasin ne sen kirjan
välissä, jonka minulle annoit. Tule, anna minä näytän ne sinulle."

Hän riensi sivuhuoneeseen, ottaen riemumielin pöydältä pienen

kultareunaisen kirjan. Hugh seurasi häntä konemaisesti tuskin
käsittäen hänen onnellista sirkutustansa.
 "Ja eikö ollut Hendonissa nuorukaisia, jotka olisivat tehneet nuo
sinun ikävät matkasi hauskemmiksi?"

Mercy avasi juuri kirjaansa hermostunein sormin, mutta pysähtyi

ja katsoi häneen hämmästynein silmin.

"Eikö? Eikö kaunista nuorta miestä, joka olisi kuiskannut sinulle,

että sinä olit sievä pikku olento, jolla ei ollut oikeutta kulkea yksin ja
surren kuihduttaa kauneuttansa? Ei ketään? Häh?"

Mercyn entinen tuskanilme alkoi palata.

"Kuule, Mercy, sano minulle totuus, sinä sukkela pikku olento,

häh?"

Mercy hypisteli hermostunein sormin kuihtuneita ruusujansa.

Hänen kurkkuansa kuristi.

Hugh katsoi hänen surullisiksi muuttuviin kasvoihinsa ja mutisi

kuin itsekseen: "Minä sanoin Bonnithornelle, että tämä pesä ei olisi
oikea paikka tytölle. Hänen olisi pitänyt viedä hänet Lontooseen."

Tytön sydän kävi sairaaksi. Kirja oli suljettu ja pantu jälleen

pöydälle.

"Ja nyt, Mercy", sanoi Hugh Ritson, "minä tahdon, että sinä olet
järkevä pikku nainen ja teet, kuten minä pyydän etkä puhu
sanaakaan. Teethän?"

Lapselliset kasvot kirkastuivat, ja Mercy nyökkäsi päätään, mutta

toisesta silmästä vierähti hereä kyynel. Sinä hetkenä hän pisti
kätensä esiliinansa taskuun, veti sieltä esille parin rannikkaita ja
koetti niitä vetää Hughin käteen. Hugh katsoi lahjaan ja hymyili
sanoen: "Minä en tahdo niitä käyttää — en tänään, tarkoitan. Katso,
minullahan on valkeat kalvostimet. Näes minä tahdon säilyttää
lahjasi ja pistän ne taskuuni. Mitä sinä murheellinen pikku raukka —
itketkö sinä taas?"

Mercyn kauniit unelmat kuolivat toinen toisensa jälkeen. Hän

kohotti hennon kätensä, kunnes se keveänä lepäsi Hughin rinnoilla.

"Kuuntele. Minä menen nyt ulos, mutta tulen pian takaisin. Minun
täytyy puhua rouva Draytonin kanssa, minullahan on jotakin
maksettavaa, tiedäthän."

Hento käsi putosi sivulle.

"Kun minä tulen takaisin, minun mukanani on ehkä ystäviä, eräs

rouva ja herra, ja minä tahdon tavata niitä yksin, aivan yksin, enkä
minä tahdo, että ne saavat nähdä sinua — ymmärrätkö?"

Äänetön, raskas murhe tuntui painuvan Mercyn sydämeen.

"Mutta ne menevät pian, ja huomenna sinä ja minä puhumme

uudestaan ja koetamme järjestää asian, niin ettei sinulla olisi aivan
niin yksinäistä, vaan että voisit katsella ympärillesi ja etsiä silmillesi
tohtorin apua ja tulisit terveeksi ja voisit unohtaa —"

"Unohtaa?" virkahti tyttö tuskin kuuluvasti. Kurkkua kuristi niin,

että sieltä vaivoin lähti mitään ääntä.

"Minä tarkoitan — se on — minä toivoin — tietysti, minä tarkoitan,

että unohtaisit kaiken ikävän Cumberlannissa tapahtuneen. Ja nyt,
mene vuoteeseen, kuten pieni hyvä tyttö ainakin. Minun täytyy
mennä. Ah, miten myöhä — katso, kello on viittätoista vailla
yksitoista ja minun kelloni on jäljessä."
 Hän astui kapakkahuoneeseen napittaen takkinsa leukaan asti.
Tyttö seurasi häntä hajamielisenä. Rouva Drayton pesi laseja
myymäpöytänsä takana.

"Tahdottekos lähettää tämän minun pikku ystäväni vuoteeseen

sangen pian", sanoi Hugh kapakan emännälle. "Katsokaa, miten
punaiset hänen silmänsä ovat. Ja pankaa hyvä tuli takkaan tuolla
vasemmalla olevassa salissa — te saatte vieraita. Teidän ei tarvitse
huolehtia vuoteista — ne eivät ole kauan. Näyttäkää minulle, mihin
aikaan menee viimeinen yöjuna kaupunkiin."

"Lontooseen? Viimeinen lähtee puoli yksi", sanoi kapakan emäntä.

"Hyvä on. Minä tapaan teitä vielä, rouva Drayton. Hyvää yötä,
Mercy, ja pidä kasvosi iloisina. Kas niin — suutele minua. Nyt, hyvää
yötä — mikä hullu, rakastava pikku hanhi sinä oletkaan — ja muista,
että olet vuoteessa ja nukut, ennenkuin minä palaan, muuten minä
julmasti suutun, niin aivan varmaan. Sinä et ole koskaan nähnyt
minua suuttuneena. No niin, älä siitä välitä. Hyvää yötä!"

Ovi avautui ja sulkeutui. Mercy palasi takaisin huoneeseensa. Se

oli iloton ja tyhjä eikä lasten onnellisia ääniä enää kuulunut. Tytön
sydäntä kivisti — se ei ollut raatelevaa tuskaa, vaan synkkää
äänetöntä tyhjyyttä, johon ei pilkottanut pienintäkään valoa, ja hän
tunsi olevansa yksin.

"Ehkäpä hän laski leikkiä sanoessaan, että kävellessäni minulla

olisi pitänyt olla joku toverina ja että pitäisi koettaa unohtaa", hän
ajatteli. "Niin, tietysti hän hullutteli, koska hän tiesi, miten minä
odotin ja odotin."
 Sitten hän otti taas kirjan, johon Hugh tuskin oli silmiänsä luonut.
Se aukesi siltä kohdalta, jossa oli kuivunut valkoinen ruusu. Sen
sydämen mahla oli painanut lehteen kellertävän merkin.

"Niin, tietysti hän puhui leikkiä", hän sanoi ja naurahti vähän, ja

silloin tipahti suuri pisara kirjan lehdelle ja kuolleelle kukalle.

Sitten hän koetti olla hyvin urhoollinen.

"Minä en saa itkeä. Se tekee minun silmäni, oi, niin kipeiksi! Minun
täytyy hoitaa niitä hyvin ja saada ne terveiksi — niin, niin. Minun
täytyy olla terve ja vahva, kun — kun — se tapahtuu."

Hän kohotti päätänsä seistessään paikoillaan, ja hymy, kuten

kevyt, kesäinen tuulahdus tyynellä vedellä, väreili hänen huulillaan.
"Hän suuteli minua", hän ajatteli, "ja tuli katsomaan minua koko
tämän pitkän — pitkän matkan."

Autuaallinen ilme kohosi nyt hänen kasvoilleen.

"Ja ellei hän tulisi takaisin, ennenkuin — ennenkuin sitten — hän

on hyvin iloinen — oi, hän on niin hirveän iloinen!"

Ajatus tulevasta hetkestä, jolloin jokin tekisi tämän pikku raukan

rikkaaksi, kuvastui hänen kasvoillansa suloisena ja suurena. Tuo
aarre olisi kaikista rakkain sen vuoksi, ettei se olisi yksin hänen
omansa. Hän palasi kapakkahuoneeseen ja sytytti kynttilän.

"Jaa, tuoko se onkin teidän sulhasenne — eikä se olekaan se

asianajaja, häh?" virkkoi rouva Drayton askarrellessansa.

"Minun ei tarvitse peittää kasvojani nyt ei nyt, kun hän on tullut

eihän?" kysyi Mercy.
 "Niin niin, hän ei näytä välittävän rahasta, ja minä olen toivonut,
että hän antaisi niitä teille, sillä kun asiat käyvät hullusti, ovat ne
ainoa, mitä jää lohdutukseksi."

Mercy näytti kuin iskun saaneelta: ääneti hän lähti

sänkykamariinsa. Mutta hänen päänsä oli liian täynnä ajatuksia, että
hän olisi voinut nukkua. Hän tutki kasvojaan peilistä ja hymyili ja
punasteli, sillä hänestä ne olivat kauniit. Ne olivat hänen omasta
mielestään nyt kauniimmat kuin koskaan ennen. Puolisen tunnin
kuluttua hän muisti, että hän oli unohtanut kirjansa salin pöydälle ja
lähti alakertaan hakemaan sitä. Kun hän oli viimeisillä portailla, hän
kuuli kiireistä koputusta ulko-ovelle.

Sinä hetkenä kaikki hänen unelmansa hävisivät kuin tuhka

tuuleen.
V LUKU.

Kun Hugh Ritson astui ulos ja saapui tielle, oli yö pimeä. Tultuaan
juuri kapakan kellertävästä valosta hänen silmänsä tuskin erottivat
jalkakäytävän tai näkivät pensaitten epäselvän mustan rivin. Ilma oli
sumuinen. Kosteus keräytyi hänen kulmakarvoihinsa ja partaansa
suuriksi pisaroiksi, ja pakkanen jäädytti ne puikoiksi. Oli pureva
kylmä. Joesta nouseva höyry levisi kylmän viiman mukana yli
suoperäisen aukeaman, joka levisi oikealle ja vasemmalle tiestä.
Synkällä tiellä oli paksulti puoliksi jäätynyttä liejua.

Hugh Ritson napitti takkinsa vieläkin tiukemmin ja riensi kuin

henkensä edestä.

"Hetkeäkään ei ole hukata", hän ajatteli, "jos aion ehtiä asemalle

siihen, kun juna pohjoisesta kulkee ohi. Olisin mielelläni tahtonut
pitää herrasmiestäni silmällä. Olisin sen tehnytkin ilman sitä
tytönlätykkää. 'Myöhästynyt', äh? Mitähän se oli, olisi hauska tietää.
Siitä saattaisi olla hyötyä."

Myötätuuleen hän kiisi yhä tulisemmin, kun hänen silmänsä

tottuivat pimeään. Hän ajatteli, että Bonnithornen sähkösanoma
saattoi olla erehdyttävä. Kenties se oli sekoittunut johonkin toiseen.
Olihan tuskin luultavaa, että Paul ja Greta olisivat joskus edes
sattuneet kuulemaan Haukka-Haikaran nimeä. Ja mitä syytä heillä
olisi yöpyä Hendoniin, vaikka ovat näin lähellä Lontoota?

Hänen ajatuksensa palasi Mercy Fisheriin. Juuri sinä hetkenä tyttö

uneksi sulounia, miten onnelliseksi hän Hughinsa tekisi sangen pian.
Hugh taas ajatteli harmitellen ja raivoissaan, että tyttö oli kiusallinen
olento, joka asettaa hänet aivan erikoiseen suhteeseen
cumberlantilaisiin. Niin, ja hän oli ainoa rengas, joka sitoi hänet
kotiseutuun. Voisiko tämä Mercy kavaltaa? — Ei! Ajatus, että Mercy
voisi saattaa hänet huonoon huutoon, oli liian raaka. Jos hän ehtisi
asemalle, ennenkuin pohjoinen juna pysähtyy, hän voisi nähdä omin
silmin, jäävätkö Paul ja Greta junasta pois. Jos he eivät jää, he ovat
siis junassa, ja hän voi astua siihen ja saapua heidän kanssaan
samalla junalla Lontooseen. Bonnithorne saattoi erehtyä.

Matka oli pitkä ja tie vaikeata kulkea. Se tuntui paljon pitemmältä

kuin hän oli luullut. Aidan ja orapihlaja-pensaan suojassa hän
raapaisi tikulla tulta ja katsoi kelloansa. Se oli juuri yksitoista. Liian
myöhään, jos kello ei ollut enempää kuin yhden minuutin jäljessä.

Silloin hän kuuli junan vihellyksen ja tuulen tohinan välistä hän

kuuli merkkisoiton. Liian myöhään, totisesti. Hän oli vielä
neljännespenikulman päässä asemalta.

Yhä hän kuitenkin kiisi asemaa kohti vähääkään enää toivomatta,

että joutuisi ajoissa.

Hän oli noin kolmensadan kyynärän päässä asemalta, kun hän

kuuli julmaa räiskettä ja jyminää, johon samalla sekaantui
inhimillisten äänten melua ja pauhinaa. Huudot, karjunta, valitus,
itku, voivotus — sekoittuivat yhdeksi hirvittäväksi hätähuudoksi, joka
yön pimeydessä herätti kammottavan kauhuntunteen.

Hugh Ritson juoksi kiireemmin.

Silloin hän näki säikähtäneitä miehiä ja naisia juoksevan

edestakaisin, milloin ne ilmestyivät valaistulle paikalle, milloin taas
katosivat pimeään. He näyttivät järjettömiltä kuin säikähtäneet
hevoset.

Pohjoisesta tulevalle junalle oli tapahtunut onnettomuus.

Kymmenisen kyynärää asemalta veturi ja kolme etumaista vaunua

oli suistunut kiskoilta ja lentänyt kauaksi pengermälle. Neljä
takimmaista vaunua oli kuitenkin pysynyt raiteilla ja pysähtynyt
saamatta mitään vaurioita.

Naiset, jotka oli saatu ulos nurinmenneistä vaunuista, hyökkäsivät

lumivalkein kasvoin läpi aseman ja hävisivät lakeudelle yön pimeään.
Miehetkin pakokauhu silmissään istuivat maahan kykenemättä
mihinkään hyödylliseen toimeen. Jotkut järkevämmät olennot
ryhtyivät arvelematta työhön koettaen saada vaunuja jälleen
kiskoille. Asemalta tuli miehiä lyhdyt käsissä; he auttoivat
loukkaantuneita ja panivat heidät pitkälleen vähän erilleen
onnettomuuspaikasta.

Tapauksen näyttämö oli laaja ja kauhea ja kuitenkin vain kaksi

tämän onnettomuuden uhreista on kertomuksemme aiheena. Kuvaus
kaikista muista — huudosta, valituksesta, itkusta, melusta ja
tuskasta — olisi tässä turhaa työtä.
 Kohtalo oli tällä hetkellä heittänyt yhteen kolme miestä, joiden
elämä tähän asti oli ollut erossa, mutta jotka tämän jälkeen olivat
hyvässä ja pahassa sidotut toisiinsa.

Hugh Ritson juoksi edestakaisin kuin juopunut. Hän tirkisteli

jokaisen kasvoihin. Hän otti lyhdyn, jonka joku oli heittänyt maahan
ja hyökkäsi haavoittuneitten luo pimeään ja kurkisti jokaista silmiin,
pysähtyi joskus ja valaisi punertavalla lyhdyllä särkyneitten vaunujen
akkunoita.

Sinä hetkenä kaikki hänen jäätyneessä sielussansa tuntui sulavan.

Nähdessään onnettomuuden tekemää tuhoa hänen oma sydämetön
suunnitelmansa tuntui kauhealta ja meni rikki. Vihdoin hän näki ne
kasvot, joita etsi. Silloin hän laski lyhdyn sivulleen ja käänsi lasin pois
päin itsestänsä.

"Seiso tässä, Greta", sanoi ääni, jonka hän hyvin tunsi. "Minä
palaan luoksesi pian. Anna minun koettaa auttaa noita tuolla."

Paul meni ihan veljensä ohi pimeässä. "Auttakaa!"

Hugh Ritson kuuli huudon pengermältä, johon haavoittuneet oli

asetettu.

"Apua, apua! Minut ryöstetään — apua!" kuului pimeästä.

"Missä te olette?" kysyi toinen ääni. "Täällä, auttakaa, auttakaa!"

Hugh Ritson juoksi sinne päin, mistä ensimmäinen ääni kuului ja

näki miehen kumartuneena jonkun maassa makaavan yli. Sinä
hetkenä toinen mies hyökkäsi esiin ja tarttui voimakkaalla kädellä
kumartuneeseen mieheen. Syntyi lyhyt, ankara ottelu. Molemmat
miehet olivat yhtä suuret ja yhtä vahvat. Kuului repeävän vaatteen
rasahdus. Seuraavana hetkenä toinen miehistä lensi pois kuin
tuulispää ja katosi lakeuden pimeään. Mutta Hugh Ritson oli
kohottanut lyhtynsä juuri, kun mies kulki ohi ja nähnyt selvästi
hänen kasvonsa. Hän tunsi hänet.

Ihmisjoukko oli kerääntynyt loukkaantuneen ja hänen

puolustajansa ympärille.

"Ettekö voinut roistoa pidättää?" kysyi joku.

"Minä pidin häntä, kunnes hänen takistaan jäi osa minun käteeni.
Katsokaa", sanoi toinen.

Hugh Ritson tunsi äänen.

"Kappale irlantilaista, karkeata takkikangasta, voisin väittää"

(tunnustellen sitä).

"Teidän olisi pitänyt tarttua hänen ulsterinsa rinnukseen. Antakaa

tämä minulle. Minä olen poliisikersantti. Mikä on teidän nimenne,
herra?"

"Paul Ritson."

"Ja osoitteenne?"

"Minä olin matkalla Morleyn Hotelliin, Trafalgar Squaressa. Mikä

paikka tämä on?"

"Hendon."

"Voiko tänne jäädä johonkin yöksi? Minulla on rouva mukana."

"Parasta on mennä kaupunkiin puoli yhden junalla, herra."

 "Rouva on liian väsynyt ja säikähtynyt. Eikö ole jotakin hotellia,
ravintolaa, yömajaa?"

Joku ovenvartija astui esille.

"Olen Haukka-Haikaran lähetti. Sinne on penikulma, herra.

Drayton — se on sen omistajan nimi — hän on itsekin täällä jossakin
— Drayton!" (huutaen).

"Voitteko toimittaa minulle ajurin, poikaseni?"

"Voin, herra."

Poliisikersantti liikahti.

"Minä voin siis tavata teitä Haukka-Haikarassa?" hän sanoi.

Hugh Ritson kuuli kaiken. Hän laski lyhdyn maahan. Pimeyden

vuoksi ei voinut erottaa kenenkään kasvojen piirteitä.

Neljännestuntia myöhemmin Hugh Ritson hengästyneenä kolkutti

mainitun kapakan ovelle. Kapakan emäntä askarteli puhdistellen
oluttynnyreitä sisällä.

"Tulkaa, joutuin!" huusi Hugh.

Ovi avautui ja hän astui sisään likomärkänä hiestä.

"Onko poikanne palannut?" hän kysyi henkeänsä haukkoen.

"Palannut, herra? Ei, herra, on ihme, jos hän tulee kotiin ennen
aamua, herra; hän ei millään tavalla —"
 "Lakatkaa lavertelemasta. Tyttö on kai omassa huoneessansa.
Menkää ja lukitkaa hänen ovensa."

Tämä tapahtui juuri sinä hetkenä, jolloin Mercy hetkisen

odoteltuaan oli palannut hermot jännittyneinä kapakkahuoneeseen.
Käännyttyään ympäri Hugh Ritson joutui silmä silmää vasten hänen
kanssaan. Kun Hugh näki hänet, valahtivat hänen tuohtuneet
kasvonsa vihasta valkeiksi.

"Enkö minä käskenyt sinun mennä vuoteeseen?" hän sanoi hiljaa,

käheästi kuiskaten.

"Minä tulin hakemaan … tulin alas hakemaan … Hugh, älä suutu

minulle."

"Mene sitten heti takaisin äläkä täällä seiso. Sukkelaan — ja lukitse

ovesi."

"Kyllä minä menen. Ethän sinä ole vihainen minulle, ethän?"

"No, en, ehk'en. Mene nyt vain — kiireesti. Kuuletko? Miks'et sinä
mene?"

"Minä tulin vain hakemaan … minä tulin vain …"

"Nyt on ihme! Mitä saakelin hullutusta tämä on? Tyttöjen

oikuttelua.
Vähät siitä. — Tuossa, emäntä, ottakaa tuli. Näyttäkää tietä. Hän ei
ole liian raskas kantaa. Ylös nyt. Mikä kyhnys te olette, vanha eukko?
Mihin huoneeseen?"

Toinen koputus ulko-ovelle. Toinen koputus ja toinen kiireellinen

touhu sisään laskemisessa.
 "Minä tulen, minä tulen!" huusi kapakan emäntä yläkerrasta.

Hän lynkytti portaita alas niin pian kuin hänen kankeat raajansa
ikinä sallivat, mutta ovelta kuului koputus uudestaan.

"Herra varjelkoon, herra varjelkoon, ja kuka se on?"

"Saatana, liikuta luitasi hieman ja päästä minut sisään."

Ovi lensi auki ulkopuolisen voiman ponnistuksesta.

Kalmankalpeana, hikikarpalot otsalta tippuen, hengitys
puuskuttavana, kaula paljaana ja paidankaulus sivulle kääntyneenä,
pala ulsterista poissa ja punainen flanellivuori näkyvässä — Paul
Drayton hyökkäsi sisään. Hän oli nyt selvä.

"Missä hän on?" kiroten.

"Minä olen täällä", vastasi Hugh astellen kapakan lattian yli kynttilä
kädessä oikealla-olevaan huoneeseen. Drayton seurasi häntä
koettaen nauraa. "Jouduinko ajoissa?"

"Tietysti jouduitte", raa'asti hymyillen.

"Minua peloitti, että myöhästyisin."

"Peloitti kai."

"Juoksin koko matkan."

"Juoksitte kai."

"Mitä te myöntelette ja mukisette?" kiroten uudestaan.

 Hugh Ritson lopetti ivansa ja osoitti revittyä ulsteria ja
epäjärjestyksessä olevaa paidankaulusta. Drayton vilkaisi pukuunsa
kynttilän valossa.

"Juoksin lakeuden yli suoraan ja tartuin orjantappurapensaaseen",

hän mutisi.

"Vaietkaa", sanoi Hugh Ritson, "nyt ei ole aikaa sellaiseen.

Katsokaa,
Drayton, minä olen suoraluontoinen mies. Älkää yrittäkö minua
pettää.
Kuten sanotte, se ei kävele. Sanonko teille, missä takki repesi ja
kaulus joutui epäkuntoon? Kappale on nyt poliisiasemalla."

Drayton liikahti harmistuneena ja katsahti raivokkaasti toiseen. Ei

ollut erehdystä, mitä hän näki Hugh Ritsonin kasvoilla.

"Minulla on omat epäluuloni, miten ja mistä syystä se tapahtui",

sanoi
Hugh.

Drayton värisi ja ikäänkuin vetäytyi kokoon.

"No, saatana! Nyt sen näkee, mikä te olette miehiänne. Te voitte

epäillä minua vaikka mistä, mutta niinä sanon teille, että te
valehtelette. Varas luulee, että kaikki varastavat. Te epäilette minua,
ja mistä? Nyt minä teidät tunnen!"

"Älkää huoliko", sanoi Hugh kärsimättömästi, "te koetatte antaa

ilkityölle liian kauniin kuoren. Minä en epäile teitä. Minä näin teidät
juuri työssä. Riittääkö se?"

Drayton vaikeni.
 "Te menette asemalle mainitun rouvan kanssa, kuten oli puhe.
Herra menee Lontooseen minun kanssani. He tulevat sittenkin tänne,
vaikka minun ensimmäinen tietoni oli väärä."

"Minä otan sen kaksikymmentä puntaa", mutisi Drayton.

"Joko nyt kelpaa? Me puhumme siitä myöhemmin." Drayton näytti

hetkeksi kokonaan tyhmistyneen. Sitten hän kohotti raivostuneet
kasvonsa ja puri hammasta. Hugh Ritson ymmärsi hänet
täydellisesti.

"Ei mitään kepposia, minä sanon sen teille. Jos te ette vie rouvaa
junaan — oikeaan junaan ja ole täällä takaisin huomenaamuna kello
puoli kaksi, te joudutte viettämään ihania päiviä Vanhassa
Baileyssä."

Drayton kohotti katseensa Hugh Ritsonin kasvoihin, mutta

samassa se vaipui alas.

"Jos minun on myönnyttävä, tapahtuu se hengen pelastamiseksi",

hän mutisi. Hän tarkasti revittyä ulsteriansa. "Minun täytyy muuttaa
pukua", hän sanoi.

"Ei."

"Rouva näkee sen."

"Sen parempi."

"Mutta sen näkevät myöskin ihmiset asemalla."

"Mitäs se haittaa? Te olette siellä Paul Ritson ettekä Paul Drayton."

Drayton alkoi nauraa — hykersi käsiään ja hohotti.