To start, here is a

...

definition of a framework:

“In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful. In computer systems, a framework is often a layered structure indicating what kind of programs can or should be built and how they would interrelate. Some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication should be standardized at some level of a network; and so forth. A framework is generally more comprehensive than a protocol and more prescriptive than a structure”

...

Agnos is a software framework that can be reused to build any acceptance system. It requires good software skills, basic EMV/payment

...

expertises, and a good knowledge of the API to start (reading documentation

...

is not enough. We recommend to follow a course). In average, between 8 and 12 weeks are required to port the system onto a new platform to be ready to start a qualification

The advantages of using that framework are:

• The system has already been certified in the past on different platforms

• The system is already deployed on the field in major markets

• The system is versatile and may be adapted to any Level3 contexts

• The system’s version that is purchased is maintained against the very last specs and frequent test plans

...

However, note that:

• The system is complex and usually requires a 3-day training session

• The system needs to be qualified before being submitted to a TA

• The system doesn’t implement any specific processor/acquirer security scheme (

...

• out of L2 scope)

This section provides a high level description of the framework:

...

• Amadis Suite model

...

Libraries enumeration

...

Development Steps presentation

...

Development Environment presentation

...

Memory Footprint example

Agnos Ecosystem

Other products are also available to extend the framework (see Agnos ecoystem below):

1. Agnos Automation (alias Atmos), a tool automating contact and contactless tests. It is used by development teams to prepare kernels for certification sessions performed by accredited laboratories

2. Agnos Certification Environment (alias ACE), a tool used during contact/contactless qualification and certification sessions including an engine used to generate binary configuration files (RAW and TLV formats) based on acquirer/processor parameters

3. Agnos Switch (alias AKTio): a transactional switch at the core of Agnos ecosystem supporting different applications

4. Agnos Payment Solution (alias Arkos), a payment solution targeting different architectures

...

Additional libraries and executables may be provided depending on the project's context. See Components page.

Libraries

Here is a brief description of the main libraries available when purchasing the product. Concerning the GPI, depending on the agreement, a specific library may be supplied. Else, it is customer’s responsibility to develop this part based on the GPI’s interface and examples developed on a given platform.

Development Steps

Here are the major steps to cross in order to port the framework in preparation to qualification tests.

Step 1: Read Manuals

This step is used to know what the documents contain to use them later as reference.

The Wiki is the main source of information. There are 2 others documents available for implementation purposes:

• [1]: Agnos Framework - L1 - Integration & Certification Guide (provided on demand) ⇒ to get details on GPI primitives

• [4]: Agnos Framework - L3 - ACE2P Protocol (provided on demand) ⇒ to integrate ACE protocol

Don’t forget that the code is also a good source of information to know how a software system works: use header files to understand API contracts (especially for the GPI and Agnos).

In order to improve our manuals, please use them as references to send us requests for support on API integration. To help us , send questions by emails and include some of the following artifacts (depending on the context):

• Tagged email’s object (mandatory): [Company name][Project name][Software component] Topic

• Reference of the unclear / incomplete section of a document

• Software components versions (mandatory)

• EMV Logs

• Card’s reference that is used

• Configuration files

Step 2: Play with the AVT

See Agnos Virtual Terminal page.

Step 3: Study the Logical Model

Step 4: Study the Physical Model

Step 5: Start Porting

See Agnos Framework Porting and/or Agnos CL Kernel Porting pages.

• Agnos Framework's Nomenclatura

• Integration Environment presentation (see below)

• Integration Stepspresentation (see below)

• Memory Foot Print example

Integration Environment

According to the license agreement, a corresponding set of artifacts is delivered. Software components have been prepared to fit to your platform and operating system:

• Use binary components for your deployment model implementation

• Use binary and development components for your implementation

The most popular platforms and operating systems of the industry are supported by Agnos (WinCE/

...

Windows/Linux/Android

...

/FreeRTOS), and proprietary environments have already been targeted.

Note that all the components

...

referred above can be packaged to support your development (Eclipse IDE along with Eclipse projects) on flexible platforms like PC (Windows

...

). Thanks to the level of abstraction that Agnos provides, it is recommended to develop on such platforms to accelerate development and test phases:

...

Agnos Virtual Terminal is a reference implementation available on Windows that can be used along with a specific Agnos integration project targeting an embedded platform. Also, systematic use of the GPI abstraction layer is a must to achieve high level of portability.

Memory Footprint

The information provided below is independent from any tool chain and any platform. It's about static memory allocation required to support Agnos Framework (no dynamic allocation as per coding pattern). Hence, it presents RAM consummation benchmark establish from the following system parameters (see Symbols, Options, and Constants):

• MAX_SUPPORTED_AID = 30 (datamngr.h)

• MAX_KERNEL = 25 (datamngr.h)

• MAX_AID = 15 (datamngr.h)

• MAX_COMBINATION_PER_TRANSACTION_TYPE = 65 (datamngr.h)

• MAX_SIMULTANEOUS_SESSION = 65 (datamngr.h)

• MAX_DRL_SET = 4 (datamngr.h)

• ONLINE_BUFFER_SIZE = 3000 (datamngr.h)

• MAX_SUPPORTED_ADF = 10 (agnostypes.h)

• AGNOSK compilation symbol = DEFINED (Agnos library)

• AGNOSCL compilation symbol = DEFINED (Agnos library)

• AGNOSISR compilation symbol = DEFINED (Agnos library)

• AGNOSCPL compilation symbol = DEFINED (Agnos library)

• AGNOSFMSG compilation symbol = DEFINED (Agnos library)

• SIZE_FOR_EMV_TAGS = 11500 (sharedram.c)

• SIZE_FOR_EMV_UNKNOWNTAGS = 2500 (sharedram.c)

• FREE_SIZE_RAM = 3000 (sharedram.c)

• SIZE_FOR_PAYPASS_TORN = 0 (sharedram.c)

• SIZE_FOR_CL_DATA_OBJECT = 10000 (sharedram.c)

• MAX_CHARACTER_PER_LINE = 16 (display.h)

• MAX_NB_LANGUAGE = 2 (display.h)

• MAX_STRING_LENGTH = 50 (display.h)

• NB_EMV_STRINGS = 34 (display.h)

• NB_ACQUIRER_STRINGS = 25 (display.h)

• MAX_NUMBER_ITEMS = 10(select.h)

• MAX_ITEM_NAME_LENGTH = 16 (select.h)

• REPLAY compilation symbol = NOT DEFINED (CAD library)

• LOG compilation symbol = NOT DEFINED (Platform library)

• TIME_STAMP compilation symbol = NOT DEFINED (Platform library)

...

Tool Chain Examples

...

ROM (kB)

...

RAM (kB)

...

Comment

...

IAR code

...

275 kB

...

110 kB

...

all major kernels along with Kizis provided to TA session

...

IAR code

...

220 kB

...

105 kB

...

Note: AVT on Linux is also available. Contact us for details.

Integration Steps

Here are the major steps to cross in order to port the framework in preparation to qualification tests.

Step 1: Train

The Wiki is the main source of information. There are few others documents available related to training modules (Training Modules).

In order to improve our documentations and our support, please use Wiki as references to send us requests. To help us, send questions by Jira and include some of the following artifacts (depending on the context):

• Object (mandatory): [Company name][Project name][Software component] Topic

• Reference of the unclear / incomplete section of a document

• Software components versions (mandatory)

• Test Case (or Card) reference

• EMV Logs, Configuration files, Transaction Related Data, …

Use our portal to contact us ofr any questions: Customer Support Portal

Step 2: Play with the AVT

The AVT is used as a reference terminal to validate the behaviors of a system under test and Amadis implementation on a PC-based system. It may also be used for training purpose.

See Agnos Virtual Terminal page.

Step 3: Study the Logical Model

Step 4: Study the Physical Model

Step 5: Start Porting

See Agnos Framework Porting pages.