Skip to end of metadata
Go to start of metadata

Glossary

  • application: part of either client or server software that is written against Common API and is independent of any particular backend
  • client: software component that uses services described by an interface
  • backend: software implementation of a particular communication mechanism between client and server
  • Franca model: all elements defined by an individual Franca IDL file (.fidl);
    full Franca model includes additionally all referenced elements that are defined externally and accessible via import statements
  • instance: distinct entity that implements an interface
  • interface: Franca IDL interface as well as its representation in C language
  • server: software component that implements services described by an interface
        Client                                      Server
    +---------------+                           +---------------+
    |  Application  |                           |  Application  |
    +---------------+                           +---------------+
    | Common API C  | - ->  Franca model   <- - | Common API C  |
    +---------------+                           +---------------+
    |    Backend    | - -> Deployment spec <- - |    Backend    |
    +---------------+                           +---------------+
            |                                           |
            +-------------------------------------------+
                            Communication

Functional Requirements

General

Alias

Description

Priority

Originator

State

Comment

<ID>

<Title>: Short caption
<Description>: This is the actual requirement text.
<Rationale>: This is a justification for the requirement.

{P1 |
P2 |
P3}

@<your.username>, <your company>

{New |
Agreed |
Rejected |
Updated}

- @<your.username>: anything to modify or add to the requirement

SW-IPC-CC-001

Mapping to C language
The component supports implementation of any data types and interfaces expressed in Franca IDL as data types and functions implemented in C accordingly to a pre-defined mapping. Parts of this implementation are generated automatically.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-002

Application interfaces determined only by Franca model
The way Franca data types and interfaces are represented in C language towards the client and server application is determined only by the corresponding Franca model. The deployment information may affect only the backend-specific code.
This allows for application code to be used with different backends without being re-compiled.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-003

Franca language version
Franca IDL v0.9 and later are supported.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-004

C language version
C language standard C99 and later are supported.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-005

Type checking on client
Static type checking by the C compiler is used to make sure that client application can access only methods, attributes and broadcasts on a particular instance that are defined by the Franca IDL description of its interface.

P1

Klaus Uhl, Intel

New

 

SW-IPC-CC-006

Type checking on server
Static type checking by the C compiler is used to make sure that server application can implement only methods, attributes and broadcasts on a particular instance that are defined by the Franca IDL description of its interface.

P1

Klaus Uhl, Intel

New

 

SW-IPC-CC-007

Default implementation on server
The code generated for server includes a default implementation of each interface defined in Franca IDL that was used for the code generation.
This lowers the effort for building a functional server implementation.

P2

Manfred Bathelt, BMW

New

 

SW-IPC-CC-008

Backend selection
Both clients and servers can select at runtime the backend used to communicate with a particular instance.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-009

Name uniqueness preservation
Given a full Franca model that is free of element name collisions, the code generated for either client or server does not result into name collisions at compile and link time.
This ensures that unique Franca IDL names are mapped to unique data type and symbol names.

P1

Klaus Uhl, Intel

New

 

SW-IPC-CC-010

Client and server in one process
All code (including both generated code and run-time libraries) that is required to implement the client- and server-side instances of the same Franca IDL interface can be compiled and linked into one program.
This allows combining the client- and server-side instances of an interface in the same process. This also implies, that given a Franca model, the symbol names generated for the same interface feature are different between client and server.

P1

Pavel Konopelko, Visteon

New

 

Instance Model

Alias

Description

Priority

Originator

State

Comment

<ID>

<Title>: Short caption
<Description>: This is the actual requirement text.
<Rationale>: This is a justification for the requirement.

{P1 |
P2 |
P3}

@<your.username>, <your company>

{New |
Agreed |
Rejected |
Updated}

- @<your.username>: anything to modify or add to the requirement

SW-IPC-CC-100

Instance multiplicity on client
Client is able to access one or many instances of a given Franca interface.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-101

Implementation multiplicity on server
Server is able to provide one or many implementations of a given Franca interface.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-102

Instance multiplicity on server
Server is able to host one or many instances of a given implementation of a Franca interface.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-103

Multiple interface versions on client
Client is able to access instances that implement different versions of the same interface.
This supports system upgrade and migration scenarios where in a particular release different servers implement different versions of the same interface.

P1

Manfred Bathelt, BMW

New

 

SW-IPC-CC-104

Multiple interface versions on server
Server is able to host instances that implement different versions of the same interface.
This supports system upgrade and migration scenarios where in a particular release the same server implements different versions of the same interface.

P1

Manfred Bathelt, BMW

New

 

Backend

Alias

Description

Priority

Originator

State

Comment

<ID>

<Title>: Short caption
<Description>: This is the actual requirement text.
<Rationale>: This is a justification for the requirement.

{P1 |
P2 |
P3}

@<your.username>, <your company>

{ New |
Agreed |
Rejected |
Updated}

- @<your.username>: anything to modify or add to the requirement

SW-IPC-CC200

Support D-Bus backend
Both client and server support communication using the D-Bus infrastructure that is provided either through a daemon (the classic solution) or through kdbus (the emerging solution).
This enables the core communication mechanism in modern GNU/Linux systems.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC201

Support in-process backend
Both client and server support communication using the in-process infrastructure (i.e., within the boundaries of a single process).
This enables connection between the client and server instances that are implemented by the same process.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC202

Support SOME/IP backend
Both client and server support communication using the SOME/IP via Ethernet infrastructure.
This enables deployment of client and server functionality across a network.

P2

Pavel Konopelko, Visteon

New

 

SW-IPC-CC203

Provide adapter for Common API C++ backends
Application code written against Common API C can be combined with the libraries provided and the code generated by Common API C++ for any supported backend.
This allows leveraging any backend available for Common API C++.

P2

Manfred Bathelt, BMW

New

 

Non-Functional Requirements

General

Alias

Description

Priority

Originator

State

Comment

<ID>

<Title>: Short caption
<Description>: This is the actual requirement text.
<Rationale>: This is a justification for the requirement.

{P1 |
P2 |
P3}

@<your.username>, <your company>

{ New |
Agreed |
Rejected |
Updated}

- @<your.username>: anything to modify or add to the requirement

SW-IPC-CC-900

Usability
The run-time API offered to the programmer should make working with the most common cases as simple as possible. For example, servers most commonly define only one implementation of the same interface. Therefore a default interface implementation on the server side should be created automatically whenever the first interface instance is created. An additional explicit call would be necessary to add an alternative implementation of the same interface.

P1

Klaus Uhl, Intel

New

 

SW-IPC-CC-901

Minimized hidden overhead
The application using Common API only provides the resources (e.g., memory, processor bandwidth, etc.) for the features that it utilizes.
This potentially extends the applicability of Common API.

P1

Pavel Konopelko, Visteon

New

 

SW-IPC-CC-902

Code generator interface
For the features they have in common, the code generators support the same syntax of command line options as the code generators for Common API C++.
This makes the development and maintenance of build scripts for Common API C and C++ easier.

P1Pavel Konopelko, VisteonNew 

TODO Items

  • Requirements on dealing with concurrency (event loop, etc.)
  • Requirements on dealing with memory allocation (custom allocators, etc.)
  • Requirements on dealing with data types
  • Any requirements derived from other open questions
  • No labels