NMBS “Ibis” mobile Architecture

NMBS “Ibis” mobileArchitecture UA – Capita Selecta Software Engineering 24/11/2008 Stéphane Tombeur stephane.tombeur@ae.be Jorne Delforge jorne.delforge@ae.be aenv/sa Interleuvenlaan 27b BE – 3001 Heverlee tel +32 16 39 30 60 fax +32 16 39 30 70 info@ae.be www.ae.be

Agenda • Software architecture ≠ software design • Business Case • Build the next generation mobile sales platform for train passengers • Functional Description • Solution Architecture • How did we design the solution architecture? • A problem/solution approach

What is Software Architecture? What word(s) pop(s) up when you think about software architecture?…

What is Architecture?

Business Architecture • It all starts with a business process… • Who is involved and how are they involved? • What is the information model?

Application Architecture • Once we have a clear vision on the business process… • Mapping process onto application(s) • Describing use-cases • Specifying components

Technical Architecture • Once we have a clear description of what is requested… • Build or buy? • How to build the application considering the requirements?

Business Case • Build the next generation mobile sales platform for train passengers

Business Case • Replace previous generation of devices called ‘Ivette’ • Limited autonomy ( < 4hrs ) • Not ‘personal’ – handed over to other operator after each shift • Fixed functionality, no extra functions possible • End-of-life (10 yrs) • Automate a number of paper forms • Extend a wider array of services to passengers • Information • Internet ticketing • Flexible payment • ‘Business agility’, ability to react to new market drivers with new kinds of tickets • Need for 3000 devices

Functional Description • That looks interesting. What does it do when I press this button?

Functional Description • Ibis is a train manager’s multi-purpose personal assistant • Sell tickets • Write fines for not having a ticket • Provide information to the customer • Write train reports • Passenger numbers • Damage and incident reports • Train security personnel can also use Ibis • They see other features enabled by their login • Write shift and incident reports

A day in the life of a train manager INA Web app Oracle db cluster Sql Server Manages Ibis backoffice Main datastore Ibis front-end datastore Accounting INA User Train Manager Train station Processes Ibis output Prepares Ibis data Uses Ibis in the field Provides wifi connectivity

Functional Description • Ibis user can • Work offline • Synchronize wirelessly in train stations • Register payments in a secure store • Accept Visa/MasterCard as payment • Use a large (Full VGA) touchscreen to interact with the device • Print (thermal) tickets, receipts and train schedules • Use the device as a cellphone for voice or SMS • Verify internet-sales tickets with a barcode reader • Provide good customer service on the train 

Functional Description • The Ibis device is • Built on a custom hardware platform • Built on a custom version of Windows • Small and lightweight • An electrical device with a battery

Ibis Solution Architecture • Ok, so you need to do all these different things... Now get to work!

Solution Architecture View Controller Ibis Mobile Device Train Manager Personal Assistant Ibis Database SQL CE database file Model Managed SQL CE API Domain layer Managed SQL CE API Business layer UI layer Data Access layer MVC-based WinForms application DB-software specific helper classes, DB-software agnostic DAC classes Class library with data, exceptions and user messages Class library with business logic .NET classes to perform replication .NET classes to perform replication Sales Component Print Component Train Reports Component ... Train Manager Uses Ibis in the field SQL Server CE Ibis Application Ibis Bootstrapper Manages synchronization, updates and Ibis startup Database system software Main application

Requirement • Highly complex business logic • Design decision: • Separation of business logic from rest of app • Impact on architecture: • Layered application • Separate functional components • Domain objects get passed through layers

Requirement • The application needs to be updated ‘in-the-field’ • Design decision: • The application will update itself through the same technique as data synchronisation • Impact on architecture: • Split application into starter exe (bootstrapper) and UI exe

Systems Management • Software updates • A device is put into the field with the latest version of the application • The main application cannot update itself due to file locking • Bootstrapper starts ‘kiosk’ application • Bootstrapper checks for update at startup (if in train station) • Uses SqlCe ‘CAB deployment’ feature to overwrite application files • User can ‘drop out’ of application to bootstrapper environment to synchronise data and update the software • System software update is not done in the field

Requirement • The user interface has a lot of screens, some may be added later, some implement similar functionality... • ... and previously we decided on ‘separation of concerns’ • Design decision: • We will implement the UI with the Model-View-Controller design pattern • Impact on architecture: • Separate layer for UI • Reuse of domain objects

Requirement • The device has a finite amount of memory... • ... and in v1 of the ‘compact’ CLR, garbage collection was not optimal • Design decision: • We will cache screen definitions for speed, but we must be careful not to use up all the RAM • Impact on architecture: • Views are grouped according to functional modules • Startup of module -> load all the screens • Change module -> destroy all the screens first

Presentation Layer

Requirement • We knew up-front that the database implementation would change (SqlServerCe -> OracleLite) • Design decision: • Separate data access logic and objects • Impact on architecture: • Data access layer • Domain objects instead of readers

Requirement • Screens are complex... • ... but a lot of screen functions are similar • Design decision: • Create reusable screen components • Impact on architecture: • Views are composite • Presentation logic becomes more generic

Requirement • Screen layout must be consistent • A lot of screens do the same basic stuff • Design decision: • Centralize layout and parts of presentation logic • Impact on architecture: • Use base class for screens • Use base class for controllers

Datum Keuzevak Tijd Keuzevak Solution Architecture

Requirement • Some data just needs to be ‘read’ and never ‘written’, but it must be _fast_! • Design decision: • Allow read-only operations straight to the database • Impact on architecture: • Implement Fast Lane Reader design pattern

Solution Architecture View Controller Ibis Mobile Device Train Manager Personal Assistant Ibis Database SQL CE database file Model Managed SQL CE API UI layer Business layer Managed SQL CE API Data Access layer Domain layer MVC-based WinForms application DB-software specific helper classes, DB-software agnostic DAC classes Class library with business logic .NET classes to perform replication Class library with data, exceptions and user messages .NET classes to perform replication Sales Component Print Component Train Reports Component ... Fast-Lane Reader DAO Train Manager Uses Ibis in the field Ibis Bootstrapper Ibis Application SQL Server CE Manages synchronization, updates and Ibis startup Database system software Main application

Requirement • Murphy is always looking over the train manager’s shoulder... • ... sometimes it just goes wrong • Design decision: • User actions must be ACID • Impact on architecture: • Use transactions • Start them from the business layer

Requirement • Data = $$$ • Sensitive data needs to be protected if the device is stolen or if it crashes • Design decision: • Encrypt credit card numbers • Double bookkeeping • Impact on architecture: • Use PKI to encrypt without a thief being able to unlock the numbers (at least in his own lifetime) • Database on compact flash + synchronized to server • Log all financial transactions to secure storage

Recap to Business Architecture • Can all business processes be automated? 100%?

Systems Management • Example of a process that cannot be fully automated: Provisioning & Inventory • Biggest challenge is keeping data ‘personal’ • Device is essentially a cash register • Amount in pocket must equal amount in register • Each device is ‘personal’, user takes it home (e.g. to recharge) • ‘Hot’ spares are located throughout the country in train stations • When a device breaks down, a service center locates the nearest spare and instructs ground personnel to switch during stopover • Spare needs to be ‘initialized’ with user’s login • When personal device is fixed, it is put in ‘hot spare location’ and scheduled to be switched again (user gets back his/her own device) • Data from spare can be synched back to personal device, but doesn’t need to be • Data is linked to user id and device id • Back office can reassign data from spare to personal device

Key Challenges • It’s all about money • Cash register needs to be 100% correct with what’s in pocket • What happens if a ticket isn’t printed correctly or needs to be cancelled • Tamper proof / Protecting OS against users • Sensitive credit card data on device • Asymmetrical key encryption of CC numbers • Credit card safety requirements • Algorithm + stoplist

Solution Architecture • Hardware (dZine – www.dzine.be) • CPU: Intel PXA255 @ 400MHz • Memory: 64MB RAM + 64MB Flash + CF Module • Screen: Full VGA (640x480) 6,4” touchscreen • Connectivity: USB, Bluetooth, Wifi, GSM/GPRS • Thermal Printer • ISO 7816 smart card reader • Contactless smart card reader • Barcode scanner • Magstripe reader • Battery lasts long enough for a full shift with smart power management

Solution Architecture • System software • Custom build of Windows CE 4.2 • Sql Server Ce (+ Sql Server 2000) • Database replication through subscriptions • File replication through CAB deployment • (Sql Server 2000 ->) Oracle database server replication • Connected to back-office through Wifi in train stations • Cisco access points • RADIUS authentication (login + MAC) • .NET Compact Framework 1.0 SP1 • Custom hardware drivers & libraries, e.g. • Printer driver • Secure store API

Solution Architecture • Application software • 1 tier, 3 layers (UI, Business logic, Data Access) • All integration to back-end done through database replication • Extensive business logic • Ticket validation • Printing component (P/Invoke to Win32 DeviceContext API) • NMBS ‘Sabin’ like price calculation component (P/Invoke) • Separate components for hardware interaction through P/Invoke • .NET CF Windows Forms • UI is MVC derived from UIP Application Block 1.0 • Presentation logic in V(iews) • Navigation and calling busines logic in C(ontrollers) • Screen data in M(odel) or ‘Data Transfer Objects’ • Separate data access logic

Layered architecture

Data Access layer

Data Access layer • Data access objects (DAO) • Manages all access to the database • Transforms query results into the desired objects • Ensures complete encapsulation of data access • Data transfer objects (DTO) • Context specific objects that reflect the information model • Classes that encapsulate only data, no behavior • Fast Lane Reader • Only for read only data

Fast Lane Reader

Business layer

Business layer • Contains all business logic • Stateless! • Uses DTOs from DAO and other services in the business layer to execute specific task • Translates input from presentation layer into DTOs for data access layer

Domain layer

Domain layer • Accessible from every module • Responsabilities: • Localization • Messageboxes • Exception managment

Presentation layer • Has its own architecture! • Each Core Module is seen as a Task • Management of Tasks is done by a TaskManager • Starting a Task • Closing a Task • Switching Between Tasks • Each Task is made of the following: • A User Process Controller (UPC) • One or Several Forms • UPC Controls navigation between forms • UPC Holds the state of the Graphical User Interface (GUI)

5 / 7 Systems Management • How do you keep 3000 machines running in the field and on-the-move?

NMBS “Ibis” mobile Architecture