D1.1 EMMA Requirements

Introduction

Current solutions for software development in complex traffic systems normally involve a series of different standards that might be incompatible with each other. This is especially true in the case of systems that combine automotive systems within a car with the available traffic infrastructure.

Despite these differences, the sensors and actuators installed in current automotive systems need to cooperate with each other in order to provide a level of service that can be acceptable for the client. Also for this reason, the number of sensors and actuators has increased dramatically in the past years, providing close to real-time information to the drivers so that they can react accordingly.

If the interaction of these components within a car is a complex issue, the cooperation with other cars or with the infrastructure is even more challenging and requires new abstractions, solutions and paradigms that support it.

For this reason, the EMMA project is working on the development of EM2P (Emma Embedded Middleware Platform), a middleware solution based on the abstraction of Wireless Cooperating Objects (WICOs), that allows for the seamless interaction of automotive components. The focus on wireless technology comes from the necessity to reduce the amount of cables within a car and from the fact that interactions with the infrastructure from an automotive system can only be performed in a wireless fashion.

As first specified as part of the Embedded WiSeNTs project, a Cooperating Object is a collection of sensors, controllers (information processors), actuators, or other Cooperating Objects that communicate with each other in order to accomplish a common task in a more or less autonomous way.

More precisely, sensors are devices that act as inputs to the Cooperating Objects and are able to gather and retrieve information either from other Cooperating Objects or from the environment they are immersed in. Controllers are devices that act as data or information processors and cooperate with sensors and actuators in order to be able to interact with their environment. Furthermore, controllers are equipped with a storage device that allows them to perform their tasks. Actuators are devices that act as output producers and are able to interact and modify their environment using, for example, some kind of electromechanical device. Finally, Cooperating Objects are equipped with communication capabilities that, for the case of Wireless Cooperating Objects (WICOs), are based on wireless technology.

The inclusion of other Cooperating Objects as part of the definition of a Cooperating Object itself indicates that these objects can combine their sensors, controllers, and actuators in a hierarchical way and are, therefore, able to create arbitrarily complex structures. For example, in EMMA each sensor within a car’s engine is a Cooperating Objects and all of them together can be considered as a Cooperating Object as well. Likewise, the car itself, a traffic light or a more complex traffic entity can be regarded as a single Cooperating Object, which is composed of other simpler Cooperating Objects.

Methodology

In order to gather the correct requirements, eliciting requirements from all the partners involved in this project and main stakeholders, it has been considered necessary to use a suitable methodology. Thus, the VOLERE methodology has been chosen as a start point for this work, adapting its requirements specification template to the particularities and needs of EMMA.

Each of the partners involved in the project follows their own processes in the requirements definition phase of their software design activities. It was important to propose a common tool to formalise the requirements that is easy to use and adapted to the needs of the project. In this context, VOLERE is a straightforward methodology that does not require a complex analysis to be applied. Furthermore, it guarantees the participation of all relevant actors, who are further involved in the design and development that have to fulfil the requirements defined.

The adapted methodology used by EMMA, has allowed the identification, and formalisation of unambiguous requirements, defining different criteria to evaluate and asses not only the correctness of the requirement, but also whether or not they have been fulfilled by the developments carried out within the project.

On the one hand, it is important to make use of a common methodology to gather, classify and assess the requirements a priori. The management of the requirements depends on this common methodology, providing the means to trace the identification, definition, assessment, formalisation and if necessary improvement of the requirements gathered.

On the other hand, the requirements should be the key to evaluate the entire project at the end of the development phase. A set of well-defined and unambiguous requirements is needed, not only as input for any further specification and development, but also as part of the evaluation framework.

In this context, VOLERE defines the gathering process and the shell to register the requirements, classified in 27 categories in 5 main groups:


Figure 1 - Shell defined by Volere

EMMA has adapted this methodology defining a new shell and limiting the number of categories of requirements to be analysed. The project drivers and project issues are relevant to the entire EMMA project and apply to the definition of the project context and framework, already defined at the Description of Work.

Nevertheless, the constraints, functional and non-functional requirements needed to be analysed for each one of the key developments within the project: the middleware, the WICOs, the operating system and the development environment. Each partner in the consortium has helped in the definition of the requirements – especially for the middleware, operating system and development environment requirements.

Each partner has analysed its own needs, identifying the requirements and defining them accordingly to the methodology proposed. The new shell proposed has been the main tool to gather the requirements in a first step, and validate them in a second one.

IDUnique id
Id for the development + numeric ID (0-99)
WICO within an automotive system Id. = W0
WICO at a car level Id.= W1
WICO at a supra-car level Id.= W2
Middleware Id. = MW
Operating System Id. = OS
Development Environment Id.= DE
e.g.: W0-01
TypeType of requirement
DescriptionA one sentence statement
RationaleA short justification of the requirement
Acceptance criteriaObjective measure to evaluate if the solution matches the requirement
AuthorPerson or entity describing the requirement
DateDate of definition
SatisfactionDegree of satisfaction if the requirement is successfully implemented
Scale1: uninterested – 5: extremely pleased
DependenciesList of requirements that depends on this one
ConflictsList of requirements that could not be implemented if this one is
Revision historyList of modifications
Comments and supporting materialOther comments and material explaining the requirement
Table 1 - EMMA shell to gather requirements

For each requirement, all fields in the shell were completed in the first step, except for the ones regarding dependencies and conflicts. During the validation process, the entire set of requirements was analysed looking for dependencies and conflicts and proposing solutions, improvements or new definitions when necessary. Ideally, at the end of the process no conflicts should appear, and the number of dependencies should be as low as possible.

Last but not least, it is noteworthy to mention that, even if the methodology followed is focused on the identification of constraints, functional and non functional requirements, the other types considered by Volere, were also studied at a high level to check the overall definition of the EMMA project.

Electronic tool

Aiming at defining an optimum and complete list of requirements, a web tool based on the Volere methodology was developed. This web tool has facilitated the definition and later validation of the EMMA requirements.

For security reasons, the access to the web tool is restricted to authorised users. Anyone can fill in the registration form to request a valid user name and password. This request is processed by the administrator who decides who must be granted access to the website.


Figure 2 – EMMA website registration form

If the administrator approves the request, then, an email with the user name and password is sent to the requester. From that moment, the user will be able to access the EMMA requirements definition website.


Figure 3 – Confirmation by email

Access to the web tool is granted after a successful identification on the system.

The application allows the administrator (a special kind of user) to control the status of the validation process from the initial definition to the final list of requirements passing through the required validation and revision status.


Figure 4 – Validation process flow chart

Definition of requirements

In this first stage all the requirements needed to accomplish the project objectives must be defined. These will be refined in future stages.

The most useful information and the main functionalities at this stage are available at the home page:


Figure 5 – Requirements definition website

Validation of requirements

After the initial definition of requirements, the validation process begins. All the requirements should be approved by all the users. At this stage, conflicts and dependencies between requirements must be detected. Furthermore, any objection must be pointed out:


Figure 6 – Dependencies, conflicts and objections list

Revision of requirements

All the dependencies, conflicts and objections encountered by the experts during the validation stage must be revised and solved. However, if the authors do not agree with the validator’s opinion, then they can make use of the “Revisor’s comments” option for pointing out their disagreement or clarifying the intention of the requirement. Note that only the authors of the requirements that have to be revised have available the icon for adding comments to the dependency, conflict or objection.


Figure 7 – Dependencies, conflicts and objections detected

The checkboxes in “Requirements revised” column and “Validator’s approvement” column help the users to check the status of the revision and together with the possibility of adding comments facilitate the interaction and communication between the author and the validator. For security reasons, the checkboxes on the “Requirements revised” column are only enabled for the authors of the requirements who have also enabled the possibility of adding comments. Moreover, for the same reason, the checkboxes on the “Validator’s approvement” column are enabled only for the author of the validation.

The revision process consists of four steps:

Validation process

All the partners involved in the definition of the EMMA requirements filled in the registration form and, after checking their requests, a private email was sent to each of them with the user name and password that granted them access to the web tool.

Three iterations were needed to complete the validation process.

At a first stage, a large list of requirements where defined with the collaboration of ETRA, TRW, USTUTT, ETRI, UNEW and CRF.

After that initial definition of requirements, the status of the process was changed to “1st iteration of validation” and all the partners were invited to evaluate this initial list. On this 1st iteration, several dependencies, conflicts and objections were detected.

Afterwards, the status of the process was changed to “revision” where the authors of the requirements had to revise their requirements taking into account the partners’ opinion.

At that stage, the authors did not always agree with the other partners’ opinion and made use of the “Revisor’s comments” for pointing out their disagreement or clarifying the intention of their requirement.

Finally, all the dependencies, conflicts and objections were resolved. And a new iteration of validation began.


Figure 8 – Real screenshot of the revision phase of the 1st iteration of validation

These processes of validation and revision were iteratively released. As said above, a total of three iterations were needed until obtaining an agreement on the list of requirements.

Introduction » Middleware