Styrandefaktoreroch ¨overgripandesystemkravvid testningavSIM...

Styrande faktorer ochovergripande systemkrav vid

testning av SIM-kortskommunikation

avThord Schibler

Examensarbete utfort vidAvdelningen for Industriella Styrsystem, KTH

&Utvecklings och forskningsavdelningen vid AU-System Mobile

9 december 1999

Mh.Th. 99-10

Industrial Control SystemsSchool of Electrical Engineering and

Information TechnologyKTH, Royal Institute of Technology

Stockholm, SWEDEN

Avdelningen forIndustriella Styrsystem

Styrande faktorer och overgripande systemkrav vidtestning av SIM-kortskommunikation

9 december 1999

Abstract

Leading aspects and overall systems requirements in testing SIM card communication

As the development of new services for mobile phones, Over-The-Air functions and applications with SIMApplication Toolkit, new demands on comprehensive test procedures arise. The objective with this MasterThesis has been to map the overall aspects on developing and testing these services, and, to evaluate andimprove the existing test process, and, if possible, also then automate the test procedure.

Measurements showed that the most time consuming parts where latencies in the GSM network and thetedious manual test labour.

An evaluation indicated that an application that bypassed the GSM network and the mobile phone wouldmake the test procedure more efficient, thus enabling Short Messages to be transferred directly to the SIMcard.A literature study on requirements engineering and automated tests was performed, enabling a require-ments capture on the test environment where the application was to operate in. To get the overall picture,an investigation of technologies was performed in the field of mobile telecommunications and especiallyrelated to SIM cards and Short Message Service, SMS.

Following the implementation and introduction of the application into the test environment there were animprovement of, as much as, 65%. The automation of the test procedure was not as successful and theimprovement was negligible compared to the bare introduction of the application in the test environment.

Keywords: GSM network, OTA - Over-The-Air, SAT - SIM Application Toolkit, SIM cards, SMS, auto-mating tests, automated test tools, mobile communication, requirements engineering, testing.

Thord SchiblerExamensarbete, 1999

i ABSTRACT



9 december 1999

Sammanfattning

Vid utvecklingen av nya tjanster till mobiltelefoner, Over-The-Air -funktioner och SIM Application Toolkit-program, kravs en omfattande testprocedur for att verifiera resultaten. Malet med detta examensarbetethar varit att kartlagga de bakomliggande faktorerna vid utvecklandet och testandet av dessa tjanstesystem,och aven forbattra den befintliga testproceduren, och eventuellt automatisera testforfarandet.

Det visade sig att den mest ineffektiva delen i testmiljon var relaterad till fordrojningar i GSM-natet samtdet enahanda manuella testarbetet.

Efter en utvardering ansags att en applikation som emulerade GSM-natet samt mobiltelefonen skullekunna effektivisera testprocessen for att pa sa satt kunna skicka SMS, Short Message Service, direkt tillSIM-kortet.For att ta fram kraven, pa testmiljon som applikation skulle operera i, utfordes en grundlig studie ikravhantering och autotester. For att fa med helheten kring testprocedurerna sammanstalldes aven ennulagesanalys av mobiltelefoni med inriktning pa SIM-kort och SMS.

Efter att ha implementerat och infort applikationen i testmiljon blev resultatet att tiden for att utfora etttest forkortades med hela 65%. Dock sa blev automatiseringen ej lika lyckad da tidsfaktorn vid automati-seringen endast forbattrades marginellt i jamforelse med den icke automatiserade losningen.

Nyckelord: GSM, OTA - Over-The-Air, SAT - SIM Application Toolkit, SIM-kort, SMS, autotester,autotestverktyg, kravhantering, mobiltelefoni, requirements engineering, testning.


ii SAMMANFATTNING



9 december 1999

Forord

Detta examensarbete genomfordes under sommaren samt hosten 1999 pa davarande AU-System Mobileav Thord Schibler vid Avdelningen for Industriella Styrsystem, KTH tillsammans med Johan Andre, vidInstitutionen for Teleinformatik, KTH.

Efter att ha arbetat narmare 21 veckor pa Utvecklings och Forskningsavdelningen pa AU-System Mobilekan jag se tillbaka pa en mycket givande och rolig tid. Dessa veckor har gett mig nya erfarenheter, ettstort antal nya forkortningar, ny kunskap samt nya vanner.

Jag vill tacka alla pa Mobile for deras hjalp och tid, speciellt Hilde Digernes och Fredrik Broman for derassvar pa fragor om SIM-kort och SMS, Simon Wallen, Fredrik Almgren, Filip Rosenbaum och KennethJohansson for deras programmeringskunskaper, Jorgen Hult, Anki Andersson och Anders Mansson forderas ovarderliga kunskaper om transportservern.

Jag vill aven passa pa att tacka Per Lundh for det mycket intressanta samtalet som vi hade.

Sedan vill jag aven tacka mina handledare, Erik Johansson, Avdelningen for Industriella Styrsystem, KTHoch Staffan Lindgren Testansvarig, AU-System Mobile. Dessa tva skall ha ett stort tack for de kommentareroch hjalp som de bidragit med under arbetets gang. De motena som jag och Erik hade innebar oftast attjag lamnade motena med fler fragor an jag hade nar vi borjade motena, med de var alla valdigt givandeoch nyttiga for mig och min rapportering.

Till sist vill jag aven tacka Johan Andre som jag utforde examensarbetet tillsammans med. Utan honomhade arbetet inte forlupit sa smidigt som det gjorde och examensarbetet hade inte varit sa givande ochtrevligt som det faktiskt blev.

Stort tack ska ni alla ha!

Thord Schibler, november 1999


iii FORORD



9 december 1999

Innehall

I Introduktion 1

1 Inledning 11.1 Presentation av AU-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Verksamheten — tillampad tele- och datakommunikation . . . . . . . . . . . . . . . 11.1.2 Kompetensen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3 AU-System Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.1 Nya tjanster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2 Den befintliga testproceduren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.3 Kommande tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Mal och syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.1 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Rapportdisposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

II Teorier 7

2 Kravhantering 72.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Ett systems anvandarcykel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Aktiviteter under kravhanteringsfasen . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Utmaningar i kravprocessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Specifikationsarbetet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Problematiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Fel i kravhanteringsprocessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Dokumentering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6.1 Helheten formulerad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6.2 Kravhanteringen i utvecklingsprocessen . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Automatiserad testning 143.1 In- och uppspelningsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Testning av anvandargranssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.2 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Problematiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1 Myterna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 Paradigmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Strategi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Klassiska misstag och problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2 Planering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.3 Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.4 Arbetet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.5 Teknologins framfart stalld mot det ekonomiska faktorerna . . . . . . . . . . . . . . 21

3.4 Vilka tester kan automatiseras? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.1 Autotestets livslangd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.2 Vardet av ett autotest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

III Nulagesanalys 26


INNEHALLSFORTECKNING



9 december 1999

4 Utredning av teknologier 264.1 Telekom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Mobiltelefoni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 GSM Historia(Global System Mobile) . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Standarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 SIM-kort, Subscriber Identity Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.1 Kort historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.2 Modul for en abonnents identitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3 Teknisk beskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.4 Den elektriska karakteristiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.5 Kortkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.6 Arkitekturen hos ett SIM-kort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.7 Funktionalitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3.8 SIM Application Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Short Message Service, SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.1 Strukturen hos ett SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.2 Anvandardatat i ett SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.3 OTA-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5 Natverksuppbyggnad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.1 SMS-overforingens primitiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.2 Protokollagren i SMS-miljon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 AviSIM OTA Service center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6.1 Systemarkitekturen hos AviSIM OTA-SC . . . . . . . . . . . . . . . . . . . . . . . . 404.6.2 Klienttjanster – Applikationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.7 Framtiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.7.1 Standarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.7.2 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.7.3 Marknaden styr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.4 Historien innehaller inte hela sanningen . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.5 IP - ar ett krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.6 Uppdelning av mobiltelefon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.7.7 WAP - Wireless Application Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 444.7.8 WIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.7.9 Framtidens aktorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

IV Genomforande 45

5 Metod 455.1 Matningar pa dagens tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Skall testerna automatiseras? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1 Ar en applikationsprototyp lamplig? . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2 Tillvagagangssatt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2.3 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2.4 Begransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.5 Arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Implementation 526.1 Utgangslaget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.1 Spraket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2.2 Loggning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.3 Anvandarkonfigurationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2.4 Iaktagelser under utvecklingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57





9 december 1999

6.2.5 Verifiering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 Resultat 587.1 Autotestets prestanda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.2 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.2.1 De bakomliggande faktorerna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.2.2 De overgripande aspekterna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3 Fortsatt arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60





9 december 1999

Figurer

1 Den overgripande systemmiljon i OTA-plattformen. . . . . . . . . . . . . . . . . . . . . . . 22 Testforfarandet vid test av stod for SIM-kort [B1]. . . . . . . . . . . . . . . . . . . . . . . . 33 Miljon for Wireless Internet Gateway och dess komponenter. . . . . . . . . . . . . . . . . . 44 Systemmiljon, dar molnet innesluter de komponenter som skulle modelleras for att eventuellt

kunna elimineras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Ett godtyckligt systems anvandarcykel [21]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 En process for kravhantering [21]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Betydelsen for ett formulerat krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Skriptkod, med och utan anvandandet av ett API [23]. . . . . . . . . . . . . . . . . . . . . . 159 Schematisk grovfordelning av en applikations innehall [23]. . . . . . . . . . . . . . . . . . . . 1910 Schematisk grovfordelning av en applikation med testpunkter [23]. . . . . . . . . . . . . . . 2011 Autotestets liv och faser [26]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2212 Koden i en applikation; kod under test, mellanliggande kod och testets kodpropagering [26]. 2213 Koden i en applikation samt testpunkter och ramverk [26]. . . . . . . . . . . . . . . . . . . . 2314 Omradet under det horisontella strecket ar stodkoden och omradet ovan illustrerar funk-

tionskoden, har med fem specifika funktioner [26]. . . . . . . . . . . . . . . . . . . . . . . . . 2315 En andring i en funktion har gjorts i kod under test (den morkare delen) [26]. . . . . . . . . 2416 Har har tva funktionsdelar andrats och en ytterligare har lagts till. For att dessa nya

koddelar skall fungera har aven en viss del av stodkoden andrats/paverkats [26]. . . . . . . 2417 Tre tester, med olika indata och resultat, men som alla anvander sig av samma stodkod [26]. 2418 Kod under test uppdelat i mindre delar med block av stodkod [26]. . . . . . . . . . . . . . . 2519 Ett SIM-korts tre olika anvandarfaser [11]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2820 Den overgripande strukturen hos ett SIM-kort [11]. . . . . . . . . . . . . . . . . . . . . . . . 2921 Exempel pa filstrukturen hos ett SIM-kort. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3022 Handelseforloppet for ett SMS for SIM-uppdatering. Env. = envelope, XX indikerar

langden pa kommandot som skall hamtas. ETSI[18]. . . . . . . . . . . . . . . . . . . . . . . 3323 Uppbyggnaden hos ett SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3524 Den generella strukturen pa SMS-enheter. SMS-GMSC anvands vid MT-meddelanden (SMS-

C −→ mobiltelefon) och SMS-IWMSC anvands vid MO-meddelanden (mobiltelefon −→SMS-C) ETSI[18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

25 MWD: De intressanta delarna i HLR ur ett SMS-perspektiv. . . . . . . . . . . . . . . . . . 3726 Protokollagren for Short Message Services. Bilden kommer fran ETSI[17]. . . . . . . . . . . 3927 Systemarkitekturen hos AviSIM OTA-SC [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . 4028 AviSIM OTA Service Centre med samtliga klienttjanster [3]. . . . . . . . . . . . . . . . . . . 4129 Testmiljon vid OTA-uppdateringar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4530 Fordelningen av tiden mellan GSM-natverksfordrojningar och det manuella arbetet. . . . . 4631 Figuren illustrerar den overgripande arkitekturen vid anvandandet av den nya testprocedu-

ren med en applikation. Den lilla gubben motsvaras av en testare vid sin dator som kor allaapplikationer [B1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

32 Arkitekturen med implementationsfaserna [B2]. . . . . . . . . . . . . . . . . . . . . . . . . . 5333 Programarkitekturen for applikationen [B2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 5434 Flodet mellan Transportservern, applikationen och SIM-kortet. . . . . . . . . . . . . . . . . 5435 De interna flodesdesignen hos applikationen. De delar med dubbelram exekverar som en

trad [34]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5536 Fordelningen av tiden i de tre fallen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


FIGURER



9 december 1999

Tabeller

1 Fel och dess orsaker som kan uppsta i en kravprocess . . . . . . . . . . . . . . . . . . . . . . 112 Innehallsforteckning for ett allmant kravdokument [21]. . . . . . . . . . . . . . . . . . . . . 113 SMS-typer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Protokoll for kommunikation med ett SMS-C och respektive tillverkare. . . . . . . . . . . . 385 Intressenter och aktorer inom telekombranchen. Tabellen illustrerar att det ar manga in-

blandade med ibland olika positioner (leverantor, tillverkare, kund etc.) och att gransernainte ar helt uppenbara. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 De narmast involverade personerna i kravprocessen. . . . . . . . . . . . . . . . . . . . . . . 48


TABELLER



9 december 1999

Ordlista & Forkortningar

ADN Abbreviated Dialling NumbersAPI Application Programming Interface,

programmeringsgranssnitt for en ap-plikation

CDMA Code Division Multiple AccessCPHS Common PCN Handset Specification

CR-verktyg Capture-and-Replay toolsin- och uppspelningsverktyg

DCS Digital Cellular SystemDF Dedicated File

filtyp pa ett SIM-kortEDGE Enhanced Data rate for GSM Evolu-

tionEF Elementary File

filtyp pa ett SIM-kortETSI European Telecommunications Stan-

dards InstituteGPRS General Packet Radio ServiceGSM Global System MobileHLR Home Location RegisterHMI Human Machine InterfaceICC Integrated circuit Chip Card, smart-

cardIMSI International Mobile Subscriber Iden-

tityIP Interaktions punkter

i ett grafiskt anvandargranssnittISDN Integrated Services Digital NetworkLND Last Number DialledMAP Mobile Application PartMCEF Mobile-station-Capacity-Exceeded-FlagME Mobile Equipment

MobilentelefonenMF Master File

Huvudfilen pa ett SIM-kortMNRF Mobile-station-Not-Reachable-FlagMNRR Mobile-station-Not-Reachable-ReasonMO Mobile Originated

Meddelanden fran mobiltelefonenMSC Mobile Switching Centre

MSISDN Mobile Station international ISDN Num-ber

MS Mobile StationMobilentelefonen och SIM-kortet settsom en entitet

MT Mobile TerminatedMeddelanden till mobiltelefonen

OA Originating AddressAddressen pa den enhet som utfardatett visst meddelande.

OS operativsystemOTA-SC OTA Service Centre

OTA Over-The-AirSamlingsnamn for de funktioner somkan andra datat pa ett SIM-kort ge-nom att skicka SMS

PCN Personal Communications NetworkPIN Personal Identification Number

PLMN Public Land Mobile NetworkPUK Personal Unblocking KeySAP SIM Application Platform

AU-Systems interna ramverkSAT SIM Application ToolKit

Funktioner som stodjer nedladding avapplikationer, menyer mm. pa en mo-biltelefon och SIM-kort

SC Service CentreSEND-SM Meddelandetyp som genereras av SIM-

kortetSFM SIM File Management

KlientapplikationSIM Subscriber Identity ModuleSME Short Message Entity

SMS-C Short Message Service CentreSMS-GMSC SMS Gateway MSCSMS-IWMSC SMS InternetWorking MSC

SMS Short Message ServiceSM Short MessageSS7 Signalling System 7STM SIM Toolkit Messaging

TDMA Time Division Multiple AccessTP-OA Transfer Protocol OA

Den adress som utfardar ett SMS, ochsom da skall ta emot ett eventuelltsvar

TR Terminal ResponseSvar som en mobiltelefon kan skickatill SIM-kortet som bekraftelse

TS TransportserverBestar av tva delar STM och SMS-


ORDLISTA & FORKORTNINGAR



9 december 1999

Gateway.UMTS Universal Mobile Telecommunication

SystemVLR Visitor Location Register

W-CDMA Wideband-CDMAWAP Wireless Application ProtocolWIG Wireless Internet GatewayWML Wireless Markup Language


ORDLISTA & FORKORTNINGAR



9 december 1999

Del I

Introduktion

1 Inledning

En overgripande bild av ett systems utgangspunkt, med forstaelse for varje systemkomponents roll, ar ettkrav for att kunna specificera och leverera ett fullskaligt utbud av tjanster och applikationer. Utvecklingenav GSM ar en evolutionar process, system, funktioner och applikationer utvecklas i olika hastighet och i va-rierande grad, dar den systemdel (av natverk/SIM-kort/mobiltelefon) som har den lagsta funktionalitetenbestammer vad systemet kan erbjuda.

I dagslaget finns det ett stort antal teleoperatorer varlden over med olika tjansteutbud. Det som dehar gemensamt ar mojligheten att erbjuda sina kunder, abonnenterna, nya tjanster i form av olikamervardesfunktioner t.ex. biljettbestallning, banktransaktioner, bokningar, vaderprognoser mm.

Vid testning av dessa olika tjanster i form av applikationer , nedladdningar och uppdateringar fran olikaklienter mot ett SIM-kort, gar dessa datameddelanden igenom hela GSM-systemet. Da GSM-natet ejgaranterar direkt leverans vid en overforing introduceras fordrojningar. Detta utgor saledes ett hinder foratt kunna utfora automatiska tester vilket gor att testprocessen ar bade tidskonsumerande och ineffektiv.De tester som utfors i dagslaget har visserligen en positiv egenskap da en nedladdad testapplikation direktkan interagera mellan SIM-kort och mobiltelefonen.

Denna testmiljo, dar meddelanden och applikationer overfors mellan SIM-kort och exempelvis en klient,ligger som grund for detta examensarbete1 och det som skall modelleras ar bl.a. hur GSM-natet kan lyftasut ur overforingskedjan. SIM-kort och ovriga systemkomponenter skall inte marka att overforingar inte garvia GSM-natet, d.v.s. systemets overforingskarakteristik skall inte paverkas av den losning som tas fram.

1.1 Presentation av AU-System

AU-System[1] grundades 1974 och blev Sveriges forsta programvaruspecialist inom datakommunikation.AU-System ar ett av landets storsta konsult- och programvaruforetag inom tele- och datakommunikation.Under varen 1999 omstrukturerades AU-System till ett mer renodlat konsultbolag. Sedan april 1999 arSchroder Ventures agare till 75% och de skall tillsammans med Ericsson, den nast storsta agaren, starkaAU-System i den fortsatta planerade internationella expansionen.

1.1.1 Verksamheten — tillampad tele- och datakommunikation

AU-System ar ett valkant namn bland de stora aktorerna in-om tele-, mobil- och datakommunikation. De har en stor an-del av landets storsta telekomforetag som kunder. Cirka 60%av verksamheten vander sig till operatorer och leverantorer inomtelekommunikation medan 40% avser projekt och losningar forslutkunder som banker, industriforetag och myndigheter.

1.1.2 Kompetensen

AU-System inriktar sig pa hur tekni-ken kan integreras och tillampas foratt bli till mest nytta for anvandarna.

”Genom att lara sig ny kommunikationsteknik i projekt for storaIT-leverantorer for att darefter tillampa tekniken i integrations-uppdrag for banker och stora industriforetag” kan man pa etteffektivt satt att bygga upp foretagets och de anstalldas kompe-tens. Ett av de mest kraftfulla satten att bygga och overforakunskap och erfarenhet ar att jobba i projekt tillsammans med kollegor i egna lokaler. Till skillnad franandra mer renodlade konsultforetag arbetar darfor 60-75% av personalen i de egna lokalerna med tillgangtill kompetenta och erfarna kollegor. Detta medfor att en kund som betalar for en konsulttjanst far mer

1examensarbetet ar aven benamnt projektet i rapporten


1(62) DEL I: 1. Inledning



9 december 1999

an den enskilde konsultens kompetens, da de aven far tillgang till den kunskap som konsultens kollegorhar.

1.1.3 AU-System Mobile

AU-System Mobile2 arbetar framforallt med systemlosningar mot SIM-kort for framforallt mobiltelefono-peratorer. De utvecklar olika s.k. Over-The-Air system, OTA, t.ex:

• OTA-Server, figur 1, ar en plattform for alla tjanster baserade pa OTA-SIM-kortshantering somstodjer metoder for fjarrhantering av applikationer i en mobiltelefons SIM-kort, lagga till och upp-datera data.

• Personaliseringssystem for SIM-kort, nedladdning av radata pa SIM-kortet (det innehall som ett korthar nar det kommer i handen pa en slutkund).

• SIM Application Toolkit, tillhandahaller funktioner som mojliggor SIM-kortbaserade applikationeratt interagera med en mobiltelefon.

Figur 1: Den overgripande systemmiljon i OTA-plattformen.

1.2 Bakgrund

1.2.1 Nya tjanster

Mojligheten att administrera SIM-kort ”over luften” oppnar nya dorrar for tjansteutbudet till anvandarna.Ett exempel pa dessa nya tjanster ar mobil e-handel dar abonnenterna anvander sin mobiltelefon for betalaoch bestalla produkter. Biljettbokning till bio eller en konsert kan snart genomforas med en mobiltelefon:

• biljetten bokas via Internet

• betalningen sker genom att kunden med hjalp av mobiltelefonen godkanner kopet

• Sakerhetsfunktionerna pa SIM-kortet kan utnyttjas for att t.ex. innehalla pengar, pa samma satt somcash-kort. Ett ytterligare exempel ar da en forsaljare vill sakerstalla en kunds identitet, vilket kanske genom att kunden konfirmerar ett meddelande som forsaljaren skickat till kundens mobiltelefon.

I Grekland har foraldrarna idag mojligheten att programmera deras barns mobiltelefoner sa att de endastkan ringa de telefonnummer som foraldrarna godkant. Detta gors via en Internetapplikation som anvandersig av OTA.

Ett annat affarsomrade som ar mycket intresserade av dessa nya tjanster ar aktiehandeln. I Singapore harmobiloperatoren Singtel redan borjat anvanda ett system som gor det mojligt for abonnenterna att kopaoch salja aktier med mobiltelefonen och i dagslaget ar det runt 400 kunder som utnyttjar dessa tjanster.Tekniken som anvands i detta system ar SIM Application Toolkit, SAT (se avsnitt 4.3.8).

2Sedan oktober 1999 heter nu foretaget Across Wireless[2]


2(62) DEL I: 1. Inledning1.2 Bakgrund



9 december 1999

OTA-meddelanden, (Over-The-Air), ger operatorerna nya mojligheter, t.ex. kan de enkelt fjarruppdateraabonnenternas telefoner med exempelvis ett nytt nummer till deras kundtjanst och lagga in det i telefon-boken pa SIM-kortet.

1.2.2 Den befintliga testproceduren

For att kunna verifiera att OTA Service Centre (OTA-SC), se avsnitt 4.6, stodjer de kort som operatorernaerbjuder sina kunder, maste dessa testas. Detta gors manuellt, se figur 2, genom att samtidigt anvandatre olika applikationer. Testforloppet genomfors pa foljande satt:

1. Valj lampliga uppdateringskommandon i OTA Service Assistant3, t.ex. uppdatera telefonboken.Sedan skickas dessa kommandon till SIM-kortet via GSM-natverket och mobiltelefonen.

Figur 2: Testforfarandet vid test av stod for SIM-kort [B1].

2. Beroende pa vilken fil som uppdaterades pa SIM-kortet finns det tva olika applikationer som kananvandas for att verifiera resultatet. Den ena visar filernas innehall i hexadecimalkod och den andravisar klartext. I de fall som det inte gar att verifiera resultatet med mobiltelefonen sa anvands nagonav dessa tva applikationer.

Vid genomforandet av detta test maste SIM-kortet flyttas mellan mobiltelefonen och en kortlasare ochdessa frekventa operationer tar mycket tid. Testet ar ocksa resurskravande da det overfors via GSM-natet, och (om det inte framgatt) sa ar det ett mycket enahanda arbete. I dagslaget ar detta det endaverifieringssattet som dessa kortstod kan testas pa.

Ett annat scenario ar nar olika SIM-kort testas for att undersoka hur de stoder OTA-meddelanden. Idessa fall ar intresset fokuserat pa hur SIM-kortet agerar efter en nedladdning. Det ar pa uppdrag avmobiloperatorerna som vill forsakra sig om att deras nya kort stoder OTA-meddelanden innan de mass-produceras och distribueras till kunderna. Dessa tester utfors pa samma satt som vid verifieringen avOTA-meddelanden.

1.2.3 Kommande tester

Mobilt Internet[5] ar det omrade som nu verkar vara det enda som ar av intresse inom telekomvarlden.Alla manniskor utrustade med en mobiltelefon skall snart kunna ’surfa pa natet’. Ett satt som mojliggor

3Service Assistant ar en applikation som anvands for att administrera filerna pa SIM-kort.





9 december 1999

detta ar att anvanda applikationer pa kortet med SAT, SIM Application Toolkit. For kunna stodja SAT-meddelanden uppkommer vissa nya krav pa Transportservern (en central del i overforingen av meddelan-den) och darmed nya testfall. De nya testfallen amnar testa stodet for SAT i Transportservern och kandelas in i tva stycken grundfall (figur 3). Mellan Internet finns en gateway, Wireless Internet Gateway,

Figur 3: Miljon for Wireless Internet Gateway och dess komponenter.

WIG, som ar uppkopplad mot en Transportserver. WIGen bestar av en Push- och en Requestserver.

Det forsta testfallet utfors enligt:

1. Anvandaren skickar en begaran (request) via mobiltelefonen genom GSM-natet till en Transportser-ver. Det kan exempelvis vara begaran om en specifik websida.

2. Requestet skickas vidare till en Requestserver i en gateway (Wireless Internet Gateway, WIG, se 4.7.8).

3. Requestservern kommunicerar med den webbservern som har den aktuella webbsidan.

4. Den begarda sidan overfors sedan till Transportservern som vidareformedlar den till mobiltelefonenvia GSM-natet.

I det andra fallet vill Transportserverns beteende ocksa undersokas, fast nu initierar Pushservern trafiken.Pushservern anvands for att overfora requests fran Internet till mobiltelefonen. Till exempel kan det varada en person vill kopa en produkt via Internet. Personen kan da konfirmera betalningen samt sin identitetgenom att acceptera ett nedladdat acceptansrequest som leverantoren skickat via Internet. Testforfarandetfor detta utfors enligt:

1. En acceptansbegaran skickas till Pushservern fran Internet.

2. Det overfors till Transportservern som skickar det vidare till mobiltelefonen via GSM-natet.

3. Mobiltelefonanvandaren accepterar eller nekar forfragan och svaret skickas tillbaka till GSM-natet.

4. Transportservern vidareformedlar svaret till Pushservern som skickar det till utfardaren.

Dessa testfall ar av intresse vid utvecklingen av automationstester, darfor att dessa tester ocksa paverkasav GSM-natets fordrojningar, vilket speciellt marks i det andra fallet.





9 december 1999

1.3 Mal och syfte

Syftet med detta projekt var att undersoka mojligheterna for automatiserade tester integrerade med vissaav AU-System Mobiles nuvarande testmetoder. Dessa metoder anvands for att testa systemkomponenternai figur 1.

1.3.1 Problemformulering

For mig, som student vid Avdelningen for Industriella Styrsystem, var projektets overgripande mal att:

• Kartlagga de olika faktorer (strategiska, taktiska och operativa) som paverkar de framtida behoveninom SIM-kortskommunikation, samt belysa de olika trender for att ta fram overgripande systemkrav.

• Ta fram en rapport som behandlar viktiga aspekter for testning samt de grundlaggande delarna forkommunikationen mellan ett SIM-kort och en server ansluten till olika klienter.

• Slutligen, med beaktande av ovannamnda kartlaggning samt aktuella trender inom omradet, till-sammans med Johan Andre utveckla en prototyp (applikation) som mojliggor testning av SIM-kortskommunikation utan att anvanda sig av GSM-natet.

Kartlaggningen behandlar aven aspekter rorande tester som utfors i dagslaget med malsattningen att tafram de delar som ar mest tidskonsumerande och enahanda och att eventuellt eliminera dem.

1.3.2 Avgransningar

Utover den direkta kommunikationen med ett SIM-kort var det, enligt figur 4, endast de delar inom detskuggade omradet som skulle utredas; Short Message Service Centre, SMS-C, mobiltelefonen och delar avTransportservern. Denna begransning gjordes initialt av AU-System Mobile som ansag att en utredningav dessa delar skulle kunna leda till en forbattring i deras testprocedurer.

Figur 4: Systemmiljon, dar molnet innesluter de komponenter som skulle modelleras for att eventuelltkunna elimineras.

Litteraturstudien valdes att endast inkludera kravhantering, autotester, GSM-systemet med fokus pa SIM-kort och Short Message Service (SMS) samt AU-System Mobiles egna system.Utover detta fanns givetvis en tidsbegransning pa 20 veckor, inom vilken arbetet skulle slutforas med enskriftlig rapport.De avgransningar som paverkat projektet mest har uppkommit vid framtagningen och implementationenav den nya applikation som utvecklats, se under avsnitt 5.2.4.


5(62) DEL I: 1. Inledning1.3 Mal och syfte



9 december 1999

1.4 Rapportdisposition

Inledningsvis i Del I presenteras AU-System Mobile och bakgrunden till projektet. Darefter foljer mal,syfte och avgransningar.

En litteraturstudie inom kravhantering med relaterade problem och vissa losningar belyses i den forstadelen av Del II. Den andra halvan av Del II behandlar autotester, hur man bor ga tillvaga och tar upp ettflertal olika aspekter kring utvecklandet av autotester.

I Del III presenteras en nulagesanalys av telekom, mobiltelefoni och hela SMS-overforingskedjan presenterasdar innehallet koncentrerats till de delar som ar narmast i testprocessen. Utredningen avslutas med enbeskrivning av AU-System Mobiles system och sammanstallningen av ett oppet samtal om framtiden medmarknadschefen for AU-System Mobile.

Del IV, behandlar genomforandet av projektet och inleds med en metodforklaring och matningar pa dagenstester. Sedan foljer en beskrivning av hur testerna kan effektiviseras via en applikation. Darefter presenterastillvagagangssattet med kravidentifiering och arkitekturen hos applikationen.I avsnitt 6 illustreras hur applikationen implementerades och designades samt vilka problem som daruppstod. Avslutningsvis kommer resultatet dar prestanda av autotestet diskuteras tillsammans med slut-satserna av inforandet av en applikation i testprocessen pa AU-System Mobile.


6(62) DEL I: 1. Inledning1.4 Rapportdisposition



9 december 1999

Del II

TeorierFoljande del behandlar de teoretiska aspekterna av kravhantering och automatisering av tester.

2 Kravhantering

2.1 Inledning

Kravhantering inriktar sig pa vad (och vilka krav som finns pa det) som skall designas snarare an hur detdesignas samt framtagningen av framtidens mojligheter for systemet som skall utvecklas.

2.2 Ett systems anvandarcykel

Enligt Linda Macaulay[21] kan ett systems anvandarcykel se ut som figur 5. Forst identifieras behovetav ett nytt system (eller produkt), darefter inforskaffas systemet, installeras och anvandare tranas foratt bruka systemet. Detta resulterar i en viss forandring i foretagets arbetssatt och vissa fall blir detaven omstruktureringar inom foretaget da nya komplexa och omfattande produkter oftast medfor nya

Figur 5: Ett godtyckligt systems anvandarcykel [21].

arbetsmetoder. Forandringarna inom ett foretag som sker vid integreringen av en ny produkt i det dagligaarbetslivet kan t.ex. vara en ny utvecklingsmetodik eller ett arbetssatt som tillater att fler medarbetarearbetar i de egna lokalerna.

Sedan, nar allt gatt bra, blir systemet helt integrerat och kan anvandas fullt ut och runt denna tidpunkt harhela foretaget anpassat sig till det nya metoderna. Till slut intraffar den tidpunkt da systemets granser ar


7(62) DEL II: 2. Kravhantering



9 december 1999

nadda. Det kan vara paverkan fran omvarlden, t.ex. nya standarder, statliga lagar etc., eller intern paverkan(storre inkop av utrustning till andra avdelningar) som far systemet att na sin grans. Da utvarderarforetaget anyo sin situation och beslutar sig for att det finns nya behov som inte ar uppfyllda inomforetaget och pa sa satt ar anvandarcykeln sluten. De behov som ej ar uppfyllda kan tas om hand pa olikasatt, man behover inte alltid kopa ett nytt system - det kan ofta racka med en uppgradering - eller attinfora en ny arbetsmetod - eller effektivisera anvandandet av resurser och personal.

Saledes ar kravhantering en lika viktig del for kunder (anvandarna), da den ger insikt i vad och vilka nyabehov som finns (och i viss man vad som kommer) samt att identifiera hur man kan uppfylla dessa krav.

2.3 Krav

Ett krav kan ses ha tva grundperspektiv; nagonting som en kund behover och nagonting som en utvecklareser behover utvecklas - dessa olika sidor betyder sallan samma sak, anser jag. Detta stodjer aven Eason[21]da han anser att perspektivet som en intressent har pa ett krav ar belagd med en barriar gentemotperspektivet en annan intressent har.

Enligt IEEE[30] 610 (1990) ar ett krav (fritt oversatt):

1. Ett tillstand eller operation som en anvandare behover for att losa ett problem eller na ett uppsattmal.

2. Ett tillstand eller mojlighet som ett system, eller systemkomponent, maste kunna na eller klara avfor att satisfiera ett kontrakt, en standard, en specifikation eller annat formellt uppstallt dokument.

3. En dokumenterad representation av villkor enligt 1 och 2.

2.3.1 Aktiviteter under kravhanteringsfasen

I sin bok om mjukvarukrav fran 1993 beskriver Davis[21] tva olika aktivitetstyper som uppkommer underkravhanteringsfasen i ett projekt. Den forsta ar problemanalysen, dar ”analytiker ’brainstormar’, intervjuarde manniskor med storst kunskap om problematiken och identifierar alla mojliga begransningar i problemetslosningar”. Denna aktivitet karakteriseras enligt Macaulay av osakerhet samtidigt som det sker en okningav information och kunskap.

Den andra aktiviteten ar produktbeskrivningen, nar ”det ar dags att sammanstalla en del svara beslut samtatt pa papper beskriva produktens forvantade uppforande och beteende”. Denna aktivitet karakteriseras avstrukturering av ideer, losning av olika synsatt och eliminering av konflikter och tvetydigheter. Vidareanser Davis att dessa aktiviteter ej nodvandigtvis behover vara gemensamt uteslutande eller sekventiella,samt att de olika tekniker som anvands inom aktiviteterna ocksa kommer att ha skilda karaktarer. I figur 6introduceras en generell modell av processen for kravinhamtning.

Grundiden (Koncept) ar den initiala faktorn som startar hela kravhanteringsprocessen och kan till exempelvara en serviceforbattring, ett framtida behov, en mindre systemforbattring (av ett redan existerandesystem) eller ett behov av att anvanda en ny tillganglig teknik. Problemanalysen inriktar sig pa att utvecklaen forstaelse for de olika problem associerade med grundtanken och konceptet. Nar sedan detta ar klart ochman erhallit full forstaelse for problematiken tas ett antal olika losningar fram for ytterligare utvarderingi en forstudiefas. Forstudien rekommenderar en losning som mer i detalj analyseras och modelleras. Varjeaktivitet bor avslutas med en kontroll av vad som sammanstallts i informationsvag samt vilken ytterligarekunskap som tillkommit. Till slut kan saledes ett kravdokument, den sa kallade kravspecifikationen, sattassamman.En av Macaulays, [21], slutsatser ar att kravinsamling ar en process mycket hart knuten till relationenmellan kund och leverantor, vilket inte borde forvana nagon. Eftersom varje skapande av en ny entitet(det kan vara precis vad som helst) inleds med ett behov hos ena sidan som den andra skall uppfylla - ochden enkla losningen ar att ha en relation mellan leverantor och kund (tillverkare - kopare) for att kunnautrona vad som kan tillfredstalla behovet. Dessutom ar processen kring skapandet av en ny produkt inteav konstant eller generell karaktar, utan i de flesta fall beroende pa vilken situation som foreligger. Detmodellen i figur 6 belyser de stora delar som kravinhamtningen bestar av och far da anses vara av engenerell karaktar.


8(62) DEL II: 2. Kravhantering2.3 Krav



9 december 1999

Figur 6: En process for kravhantering [21].

2.4 Utmaningar i kravprocessen

Bubenko[22] lagger i sin ”Challenges in Requirements Engineering”, 1995, fram en del intressanta aspekterkring svarigheterna med kravhantering. Bland annat diskuteras de grundlaggande problemen vid kravhan-tering relaterade till foretagsledningar, organisationer, anvandare, ovriga intressenter, metodik, verktyg ochutbildning. Bubenko ser kravhantering som det tvarkunskapsomradet av kommunikationen mellan orga-nisationella aktorer och deras visioner, intentioner och aktiviteter vad galler deras behov av support samtatt utveckla och vidmakthalla en adekvat kravspecifikation for ett informationssystem.

2.4.1 Specifikationsarbetet

En kravspecifikation spelar manga olika roller vid utveckling och upphandling av ett system. Dels ar det ettkontrakt mellan olika intressenter, samtidigt som det ar en arkitektur som ar en implementationsoberoendebild av det framtida systemet. Nar sedan systemet ar implementerat bor kravspecifikationen brukas som ettkontrollprotokoll for att jamfora det fardiga systemet med det som bestalldes. I det ideala fallet skulle enkravspecifikation innehalla delar som beskriver vilka basantaganden som ar gjorda, bakomliggande behov,vilken kunskap det finns inom den aktuella problemdomanen - allt detta for att understryka och stodjadesignen och implementationen av ett informationssystem. En ideal specifikation bor kunna besvara fragoroch behandla amnen som:

• Varfor behovs systemet?

• Vilka ar (de bakomliggande) malen for omgivningen/applikationen?

• Vilka prioriteringar finns (finns det delar som ar viktigare an andra)?

• Vilka ar foretagets verksamhetsomraden (mal, affarsregler, aktiviteter)?

• Hur och av vem genomfors de olika delarna?

• Vilka ar de funktionella respektive icke- systemkraven?

Utover den beskrivande delen behovs aven metoder i de inledande faserna for att pa ett konstruktivt,samarbetsmassigt och effektivt satt fa med anvandarna.


9(62) DEL II: 2. Kravhantering2.4 Utmaningar i kravprocessen



9 december 1999

Vidga begreppenDen standigt okande vikten av informationssystem, for att kunna klara av att vara verksam i ett affarsomrade,pekar pa att forstaelsen, for dels sjalva affarsomradet samt att detektera nya behov och krav, maste okas.Ett val fungerande system kan vara en (konkurrensmassig) tillgang medan ett system som ej ar anpassattill affarsomradet kan utgora ett hinder.Det som jag ser som har ar att det ar en skiftning i hur krav skall beaktas; fran det mer tekniskt oriente-rade aspekterna mot ramverk som modellerar ’foretaget’ (affarsomradet och affarsmetoder, affarsmal ochaffarsregler) samt de tekniska aspekterna.

2.4.2 Problematiken

Foretagsledningen ar oftast inte medveten om den strategiska rollen som kravidentifieringsarbetet spelaroch darfor far detta arbete inte de resurser och det kapital som behovs. Vidare ar ledningens involvering ochatagande i kravhanteringen generellt sett lag och detta implicerar att arbetet med kravhantering normaltinte forknippas med affarsvisioner, affarsmal, forandringar i affarsprocesser eller andra organisatoriskaforandringar.Allmant galler att organisationer inte tycks lara sig fran tidigare erfarenheter av kravhantering[21] - spe-ciellt brukar inte kravspecifikationer anvandas som kunskapskallor for framtida kravhanteringsprojekt.Organisationer anser sig oftast ligga pa en ganska hog mognadsniva inom informationssystem och krav-hantering. Darfor anses det oftast inte vara nodvandigt att vidareutveckla metoder och oka kunskapeninom kravhantering hos anvandare och ovriga intressenter vilket medfor problem i kommunikationen mel-lan inblandade parter (utvecklare och anvandare) och en lag validitet hos kravspecifikationerna.Anvandarna, a sin sida, antar aven de att systemutvecklare ”kan sin kravhantering” och godkanner glade-ligen krav utan att till fullo forsta dess innebord. Detta ar grunden till att anvandare och systemutvecklarear aktiva deltagare i kravidentifieringsprocessen - trots att de inte har full forstaelse for vad den andraparten egentligen menar och ej heller har tillracklig kunskap om hur denna forstaelse gemensamt kan (ochskall/bor) hojas.

Verktyg och metoderDet finns idag ett stort antal kommersiella systemutvecklingsmetoder och CASE-verktyg4, de flesta ardock inriktade mot de sista faserna i ett systems livscykel. De saknar en strukturerad hantering av deinitiala stegen i analysen av affarsmal och kravgenereringsstegen samt att kunna ga mellan en svag in-formationsdoman till en formell sadan. Macaulay anser att dagens tillgangliga metoder ar inte lampligaatt explicit ta hand om en strukturerad insamling och representation av organisatorisk och affarsrelateradkunskap.

De metoder som finns, kommersiella och teoretiska, innebar ett hinder for utvecklarna, anser Macaulay,da de ej helt kan analysera kvaliten pa en kravspecifikation. T.ex. ar det inte sant att en kravspecifikationalltid i alla situationer maste vara 100% komplett, otvetydig etc. Det finns en mangd olika faktorer ochsituationer som paverkar och styr den nivan av detaljer och fullstandighet som en specifikation har.

De andringar som gors i designstegen dokumenteras sallan i den ursprungliga kravspecifikationen. DeCASE-verktyg som idag finns tillgangliga ar inte anpassade till kravhantering, da de ar amnade for mjuk-varuutveckling och mojligheten att kunna spara beslut inte stods. Vidare sa finns det heller inga verktygsom klarar av att hantera alla de olika dokumenttyper som ett kravarbete genererar, sasom rapporter,memos, e-post, video etc.

Dock sa tror jag att ett effektivt e-postprogram klarar av stora delar av det dokumentverktyg somMacaulaysaknar. Dagens e-postprogram ar utformade for att just visa och hantera en stort antal olika dokumenttyperoch filformat.

Grundlaggande fragestallningarEtt av de mest grundlaggande problemen ar att det finns for fa praktiska undersokningar av kravhantering.Detta innebar att det uppkommer att antal fragestallningar relaterade till hur och varfor ett visst verktyg

4Ericssons PROPS, Rationals ROP [28]


10(62) DEL II: 2. Kravhantering2.4 Utmaningar i kravprocessen



9 december 1999

anvands; Vad finns? Vilka relevanta problemerfarenheter finns? Varfor anvands metod A framfor metodB? Blir det farre fel med vissa analyser an med andra? och i sa fall varfor? Den akademiska utbildningeni mjukvaruutveckling och kravhantering ar enligt min uppfattning inte inriktade pa praktiskt arbete ochdarfor finns det ett behov av att se over dessa utbildningar med fokus pa att ta fram ingenjorer och inteprogrammerare.

2.5 Fel i kravhanteringsprocessen

Enligt Lyytinen och Hirchheim (1987)[21] kan ett misslyckande av ett (informations)system delas in i fyraklasser. Dock sa anser Macaulay att endast tre av dessa ar intressanta:

1. Processfel, relaterat till den utvecklingsprocess, dar budget, tid eller nagon annan typ av resursallo-kation har passerat gransen dar forvantningarna pa det foreslagna systemet negligerats eller dar deallokerade resurserna resulterar i ett oanvandbart system.

2. Samspelsfel/Interaktionsfel, ”argumentationen att en lagre utnyttjandegrad av systemet an forvantatskan tolkas som ett misslyckande”

3. Felaktiga forvantningar, systemet moter ej de forvantningarna som stallts upp av de involveradegrupperna (intressenterna).

Tabell 1 illustrerar exempel pa orsaker som genererar de olika felen. Vart att notera ar att kommunikationenmellan inblandade parter slar hardast och ger mest konsekvenser nar det intraffar.

Typ av fel Process Interaktion Forvantan

Brist pa processystematik �

Dalig kommunikation mellan manniskor � � �

Bristande kunskap eller gemensam forstaelse � �

Otillfredsstallande dokumentation � �

Dalig resurserhantering �

Tabell 1: Fel och dess orsaker som kan uppsta i en kravprocess

2.6 Dokumentering

Enligt IEEE 830-1984, ”IEEE Guide to Software Requirements Specifications”[21, 30], kan en innehalls-forteckning over ett kravdokument ha foljande struktur:

1 Introduction1.1 Purpose1.2 Scope1.3 Definitions, Acronyms, andAbbreviations1.4 References1.5 Overview2 General Description2.1 Product Perspective2.2 ProductFunctions2.3 User Characteristics2.4 General Constraints2.5 Assumptions and Dependencies

3 Specific Requirements3.1 Functional Requirements3.1.1 Functional Requirement 13.1.1.1 Introduction3.1.1.2 Inputs3.1.1.3 Processing3.1.1.4 Outputs3.1.2 Functional Requirement 2. . .3.1.n Functional Requirement n3.2 External Interface Requirements3.2.1 User Interfaces3.2.2 Hardware Interfaces3.2.3 Software Interfaces3.2.4 Communication Interfaces

3.3 Performance Requirements3.4 Design Constraints3.4.1 Standard Compliance3.4.2 Harware Limitations. . .3.5 Attributes3.5.1 Security3.5.2 Maintainability3.6 Other Requirements3.6.1 Database3.6.2 Operations3.6.3 Site Adaptation. . .AppendicesIndex

Tabell 2: Innehallsforteckning for ett allmant kravdokument [21].


11(62) DEL II: 2. Kravhantering2.5 Fel i kravhanteringsprocessen



9 december 1999

2.6.1 Helheten formulerad

Denna uppbyggnad, enligt tabell 2, mojliggor ett enkelt satt att fa med de delar och aspekter som ettvalskrivet kravdokument bor innehalla, utover de olika och styrande satskriterierna (figur 7):

Figur 7: Betydelsen for ett formulerat krav

a) Entydigt/Korrekt: Krav skrivs oftast i vanliga sprak dar satser kan ha olika betydelser. Dar det artillampbart bor man anvanda formella sprak som kan detektera lexikala, semantiska och syntaktiskaoegentligheter.

b) Komplett: Ett kravdokument ar komplett om det innehaller samtliga signifikanta krav (funktionella,prestanda, designbegransningar etc.).

c) Testbar och Verifierbar: Ett krav skall vara av sadan art att det ar mojligt att verifiera kravet,d.v.s. kravet skall vara matbart.

d) Konsistent: Ett krav skall endast ha ett namn och beskrivas med samma termer (vid alla refere-ringar till det).

e) Sparbart: Harkomsten av krav bor alltid klart framga for att pa sa satt mojliggora sparbarhetbakat for att se vilket eventuellt beslut som foreligger, samt sparbarhet framat for att mojliggora en’oversikt’ av de dokument som harror fran ett visst kravdokument.

Man bor aven ta med motivet bakom ett krav for att ytterligare belysa vilka faktorer som ligger till grundfor kravet (m.a.o. ett satt att oka att forstaelsen av kravets ursprungliga betydelse). Detta kan vara tillhjalp nar utvecklingen av ett system och dess miljo genomgar forandringar5.

Aterkoppling till de efterkommande fasernaUtover att kraven skall vara val beskrivna bor ett kravdokument vara modifierbart, d.v.s. skriven pa ett en-hetligt satt, t.ex. enligt IEEE-guiden i tabell 2. En enhetlig struktur forenklar bade framtida modifieringaroch lasbarheten vilket gor dokumentet mer anvandbart (m.a.o. sa att det aven kan vara till anvandning idrift och underhallsfaserna).

5Intressant aspekt som min handledare vid Avdelningen for Industriella Styrsystem, Erik Johansson, papekade


12(62) DEL II: 2. Kravhantering2.6 Dokumentering



9 december 1999

Macaulay understryker aven att det skall vara en distinkt skillnad mellan utvecklingsmodellen och denmodell som beskriver mjukvaruimplementationen. Utvecklingsmodellen bor, enligt Verheijen och Van Bek-kum, 1982[21], ocksa innehalla foljande delar:

1. En hog abstraktionsniva, fran anvandarnas perspektiv, och den bor innefatta och integrera anvandar-nas koncept pa ett tidigt stadium.

2. Mansklig lasbarhet. Det anvanda spraket bor vara av enkel natur, vilket i sin tur innebar problemvid anvandningen av kravdokument skrivna med ett formellt sprak. Det viktiga ar att det inte finnssvarigheter att forsta den beskrivna modellen.

3. Precision, ett hognivasprak bor anvandas for att definiera tillampningsomrade, systemgranser, namn-givning av objekt, regler, processer mm.

4. Specifikationens helhet. Den anvanda modellen skall pa ett klart och tydligt innefatta alla aspekter.

5. Overforing till efterfoljande faser, detta med anledning att de faser som foljer kravdefinitionsfasenskall kunna fa en konstruktiv ’input’, sa maste modellen ha en sadan struktur att det lampar sig attoverfora den information som behovs till de efterkommande faserna.

Lasbarhet stallt emot formalismI de tva senaste upprakningarna, 2 respektive a), introduceras en tvetydighet. I det ena fallet menar manpa att formella sprak som kan detektera lexikala, semantiska och syntaktiska oegentligheter bor anvandasfor att beskriva krav. I det andra fallet foredras att spraket bor vara av enkel natur for att oka forstaelsen.Vad som ar bast avgor situationen; om det ar en intern forstudie tror jag att spraket ar mer at det lasbara,da lasaren kan fraga forfattaren, som en kollega, vad en formulering syftar till. Men om det ar en offert anserjag att det lonar sig att anvanda ett mer strikt och formellt sprak. En allmant bra metod ar att definieraterminologin (ord, formuleringar, forkortningar, namnkonventioner etc.) som en del i kravdokumenten.

2.6.2 Kravhanteringen i utvecklingsprocessen

Utover ett valformulerat kravdokument behover processen for kravhanteringen fogas samman med utveck-lingsprocessen. Hur detta gors pa basta satt finns det nog ingen som vet - det ar darfor det finns sa mangaolika utvecklingsmetoder och tillhorande verktyg6.Det som kravprocessen tillfor utvecklingsprocessen ar:

1. en overenskommelse - vad som galler for de inblandade intressenterna

2. en beskrivning av kraven for utvecklarna - de far en (helhets)bild av vad som skall utvecklas

3. begransningarna - inom vilka granser som kraven galler och haller, samt

4. en informationsbas - bakgrund (motiven), vilka faktorer som ar intressanta.

Min uppfattning ar att resultaten ifran processen av kravhantering, krav och kravdokument, maste for-medlas vidare till de foljande utvecklingsfaserna. Jag tror att detta leder till en battre hantering och krav- kraven kan pa sa satt bli lattare att uppfylla och genomfora om de iblandade personerna har tillgang tillkravdokumenten. Detta forutsatter visserligen att de inblandade personerna aktivt tar del av materialet.

6Bakom referensen Tero Ahtee[28] doljer sig mer an 60 olika CASE-tools och utvecklingsmodeller


13(62) DEL II: 2. Kravhantering2.6 Dokumentering



9 december 1999

3 Automatiserad testning

Dagens mjukvarusystem ar oftast utrustade med grafiska anvandargranssnitt (Graphical User Interfaces).Med alla olika mojligheter som finns att interagera med anvandarna och det stora antalet kontrollelement(knappar, rullgardinmenyer, toolbars) som anvandargranssnitten har, blir testningen av dessa extremttidskravande och kostsamma. Att utfora dessa tester manuellt ar arbetsamt, monotont och ouppskattat avde flesta utvecklare och testare. Det finns dock mojligheter att automatisera dessa tester med kommersiellamjukvarubaserade verktyg.

3.1 In- och uppspelningsverktyg

In- och uppspelningsverktyg, Capture-and-Replay tools (CR-verktyg), ar oftast objektorienterade och upp-fattar alla delar i ett grafiskt anvandargranssnitt som objekt och registrerar de olika delarnas innehall(namn, farg, varde) och inte bara dess X/Y-koordinater vid ett musklick. Vid en inspelning spelas allmanuell anvandarinteraktion pa testobjektet in och stegen sparas i ett skriptsprak med liknande syntaxoch semantik som C eller Basic. Ett inspelat skript kan sedan spelas upp hur manga ganger som helst.Om testobjektet under en uppspelning upptrader annorlunda an det gjorde vid inspelningen registrerasdetta som ett fel av CR-verktyget.

3.1.1 Testning av anvandargranssnitt

I ett system med ett grafiskt anvandargranssnitt ar alla funktioner i granssnittet representerade via inter-aktions punkter (IP) och dessa aktiveras genom att markera dom, t.ex. med musen. Att identifiera samtligaIP ar inte nagot storre problem for en manniska aven om, eller nar, det sker forandringar i granssnittet.Denna identifiering skall aven CR-verktygen klara av, vilket av forklarliga skal inte ar det lattaste attimplementera. CR-verktygen kanner igen delarna i det grafiska granssnittet via deras objektidentifierareoch ar darfor kansliga for andringar av vardet pa dessa. Till detta tillkommer aven att vissa mjukvaruut-vecklingsmiljoer ibland andrar identifierarna pa grafiska granssnittsobjekt, utan att underratta utvecklaren(darfor att utvecklaren inte skall behova ha ansvar for tilldelningen av de individuella identifierarna). Sasituationen vid anvandandet av CR-verktyg och forandringar i det grafiska anvandargranssnittet gor dessatestfall ganska problematiska.

For att ge mjukvaruapplikationer ett enhetligt anvandarintryck, har utvecklare forsokt ta fram layoutregler,Style Guides, dar det exempelvis finns beskrivningar som:

• ’OK’ och ’Cancel’ ar alltid placerade vid botten eller till hoger och aldrig till vanster eller hogst upp.

• Alla falt maste vara nabara via tabbar i samma ordning

3.1.2 Regressionstest

Ett regressionstest ar ett test som programrelease N passerat och som release N +1 testas med for att sehur N + 1 versionen upptrader.

Regressionstestverktyg for grafiska anvandargranssnitt finns i tva varianter:

1. Forsta generationens inspelningsverktyg. Dessa spelar in musrorelser eller tangentnedtryckningaroch tar ogonblicksbilder av ’pixlarna’ pa skarmen. Dessa verktyg genererar tester som inte gar attunderhalla, for nar det sker en minsta andring pa skarmen7 sa slutar testet fungera. Skarmbildensutseende och layout andras vanligtvis sa pass ofta att supporten (de manuella uppdateringarna) fordessa tester blir testpersonalen overmaktig och darmed blir testerna oanvandbara och dyra.

2. Andra generationens verktyg liknar de forsta men har aven mojligheter for att anvanda testskript.Dessa ar anvandbara da man kan kapsla in skriptkod med ett eget utvecklat API (ApplicationPrograming Interface). Ett inspelat skript kan ha liknande innehall som figur 8-a illustrerar, medansett skript, med ett API, kan ha strukturen som i figur 8-b.

7klockan, e-post indikation etc. ar forodande vid inspelningen av ett test.


14(62) DEL II: 3. Automatiserad testning



9 december 1999

text $main.accountField "12"click $main.OKmenu $operationsmenu $withdrawclick $withdrawDialog.all. . .

select-account 12withdraw all. . .

a) b)

Figur 8: Skriptkod, med och utan anvandandet av ett API [23].

Med ett valutformat API (vilket inte ar det enklaste att ta fram) sa kommer de flesta andringarnai anvandargranssnittet endast att paverka implementationen av API-funktioner, som ’withdraw’,att behovas goras om.

En annan valanvand metod ar att anvanda datadrivna tester (se 3.2.3.3) som aven de abstraherar delarav testet och mojliggor stabilitet vid forandringar i anvandargranssnittet.

3.2 Problematiken

3.2.1 Myterna

Foljande pastaenden ’Manniskor utan storre programmeringserfarenheter kan via dessa autotestverktygsnabbt skapa sig en bank av testsviter’, ’Verktygen i fraga ar enkla att anvanda’, ’Underhallning av test-sviterna innebar inga problem’ ar enligt Cem Kaner[24] ingenting annat an myter. Myter som sprids vialeverantorer av autotestverktyg – de vill salja sina produkter, samt av chefer – de arbetar inte med testningsamt av testare – som egentligen borde veta vad det innebar att automatisera tester.

Ytterligare problem relaterade till tester ligger i att avgora om ett testarbete ar lyckat eller inte. Codecoverage ar en metod som tar fram matetal som kan anvandas vid jamforelser. Den har tva fordelaktigapastaenden:

1. Om en kodrad aldrig exekverats i ett test kommer dess fel inte att upptackas.

2. Testsviter ar i allmanhet for stora samt komplexa och tester som inte tillfor nagot av varde kanslangas.

Men ur dessa fordelar brukar aven tva vanliga missuppfattningar utkristalliseras, enligt Kaner:

1′. Varje test skall kora igenom varje rad kod i en applikation.

2′. Ett test som inte tillfor nagon ny code coverage tillfor inget varde.

Utover dessa tva missuppfattningarna finns det ett tredje problem som harur fran att code-coverage arkonkret, objektiv och matbar. Detta tilltalar de som vill se resultat (ledning/chefer) men resultatet ar inteen sanning - det borde snarare ses (och aven anvandas) som en grov uppskattning av vilka koddelar somundersokts i en applikation.

Kaner[24] menar att, trots en stor osakerhet, det finns varde i att utfora code coverage. Da det leder tillatt testarbetet kan bli mer strukturerat och fokuserat pa de delar dar det dels visat sig finnas fel och delsde delar som annu inte testats.


15(62) DEL II: 3. Automatiserad testning3.2 Problematiken



9 december 1999

3.2.2 Paradigmen

Paradigmen for att anvanda ett autotestverktyg ar mycket enkel:

1. Tag fram ett testfall och kor det.

2. Om programmet ej klarar testet skriv en felrapport. Nar felet ar atgardat sa fortsatter man koraprogrammet.

3. Om programmet klarar testet automatiseras det och sedan kors testet igen (via ett skript eller medhjalp av en uppspelningsfunktion). Nar testet ar klart sparas skarmbilden tillsammans med testfallet.

4. Nasta gang testfallet kors ar det bara att jamfora resultatet med det som sparats. Om sedan resul-taten ar lika har programmet klarat testet.

Cem Kaner[24] menar att kring denna paradigm finns ett flertal problem som oftast innebar ett resultatsom tagit mer tid och darmed kostat mer an ett motsvarande manuellt test. Vanligtvis tar denna auto-testprocedur allt mellan tre till tio ganger langre tid for att skapa, verifiera och minimalt dokumentera anden tid det tar att en gang kora igenom det manuellt. Det finns manga tester som behover automatiseras,men for alla de tester som bara kors enstaka ganger ar detta inte en forsvarbar metodik.Vidare skapar metodiken risker for extrautgifter da kostnaden for att hitta och atgarda ett fel okar medtiden. Saledes om en testare borjar med att skapa testskript kan det leda till att det endast blir enforsening i upptackten av felen. I jamforelse med en kompetent och erfaren manuelltestare ar autotesterinte sa kraftfulla, da

– de oftast ar tester som programmet redan passerat en gang och detta innebar att det inte ar satroligt att det kommer att upptackas sa speciellt mycket fler nya fel (som ar relaterade till testfallet,se 3.4.2). De fel som upptrader ar oftast vid sjalva skapandet av autotestet – vilket egentligen armanuellt testarbete.

– testare brukar automatisera de testfall som ar enkla att kora just for de ar mindre avancerade attutforma och darfor att verktygen inte ar anpassade for mer storskaliga och komplexa testfall.

De testsviter som anda spelats in maste kunna underhallas nar programmens anvandargranssnitt andras,vilket hander ofta8. Det som skall forsvaras ar hur mycket merarbete dessa forandringar innebar fortestsviterna.

3.2.3 Strategi

For att kunna utveckla autotester kravs en strategi och den som Kaner[24] foreslar bestar av foljande sexpunkter:

1. Forma ledningen att inte forvanta sig allt for mycket vad det galler de tidsmassiga fordelarna avautotester.

2. Inse att autotestutveckling faktiskt ar mjukvaruutveckling.

3. Anvand en datadriven arkitektur.

4. Anvand en ramverksarkitektur.

5. Forsta personalen.

6. Beakta andra metoder for automatisering.8T.ex. en ny meny introduceras, eller spraket andras fran engelska till svenska.





9 december 1999

3.2.3.1 – Forma ledningen att inte forvanta sig allt for mycketEffekten och fordelarna av att anvanda ett regressions autotestverktyg utvecklat for programrelease Nkommer forst i releasen N + 1. Ett regressionstest utvecklat for release 1 kommer, efter en viss tid, medstor sannolikhet inte att upptacka nya felaktigheter i denna release. Det mest fordelaktiga ar att testet kananvandas for release 2 och med betydligt storre sannolikhet upptacka fel i denna release. Forutsattningenfor detta ar att det skett forandringar i de funktioner som direkt eller indirekt anvands och testas avregressionstestet. T.ex. kompabilitet med aldre mjuk- och hardvara kan vara lamliga regressionstester.

3.2.3.2 – Inse att autotestutveckling faktisk ar mjukvaruutvecklingUtan en klar och realistisk planering gar det inte att utveckla testsviter som skall vara anvandbara ochoverleva flera releaser och som dessutom kan vara storre an applikationen sjalv och aven darutover skallvara enkla att underhalla for att vara kostnadsmassigt forsvarbara under projektets gang. Automationav mjukvarutestning liknar det arbete som mjukvaruutvecklare utfor, fast har ar det testare som skriverautomationskoden och de maste (som brukligt i mjukvaruutvecklingsprojekt):

• forsta kraven

• skapa en arkitektur som tillater effektiv utveckling, integrering och underhall av funktioner och data

• skapa och folja ’egna’ standarder (namnkonventioner, strukturer etc.) utover de redan existerande

• vara disciplinerade

De tester som utvecklas maste aven de testas. Testutvecklarna introducerar pa samma satt som mjukvaru-utvecklarna fel i ’processen’. Hur manga och hur stora dessa fel ar en icke-trivial uppgift att losa, men narde intraffar ar de felen lika allvarliga som de fel som mjukvaruutvecklarna introducerat. Speciellt om detar dubbelfel som ar svara att upptacka och troligtvis valdigt kostsamma nar de upptacks.

3.2.3.3 – Anvand en datadriven arkitekturEtt valdesignat datadrivet angreppssatt underlattar planeringen och underhallet av testerna. Detta galleraven for testare utan programmeringsbakgrund da metoden ar enkel att hantera. (I en datadriven metodkoncentreras arbetet pa att undersoka in- och utparametrar genom att, via tabeller eller matriser, stallaupp parametrarna och sedan lata ett verktyg traversera igenom samtliga fall).

3.2.3.4 – Anvand en ramverksarkitekturMed ett ramverk kan man isolera applikationen under test fran testskripten genom att anvanda funktioneri ett gemensamt funktionsbibliotek. De som sedan tar fram testskripten anvander dessa funktioner som omde ar grundkommandon i testverktygets programmeringssprak. Ett ramverk innehaller flera olika typer avfunktioner, t.ex. valdigt enkla wrappers9 kring enkla applikationer eller verktygsfunktioner men ramverketkan aven innehalla valdigt komplexa skript for mer integrerade uppgifter. Grundfunktionaliteten i ettramverk bor innehalla foljande komponenter:

• ’alla funktioner hos en applikation’, d.v.s. menyval, inmatning av variabler och kommandon. Omsedan anvandargranssnittet andras ar det bara att andra i dessa basfunktioner

• ’enkla wrappers kring alla basfunktioner hos testverktyget programmeringssprak’ vilket mojliggorenkel hantering av fel eller uppdateringar i testverktygets skriptsprak.

• ’sma, enkla och frekvent anvanda konceptuella funktioner’, vilket sparar tid och forenklar underhalletav skripten.

• ’storre (komplexa) frekvent anvanda delar av testfall’, dessa ar i och for sig motsagelsefulla da det arsvart att just identifiera de gemensamma delarna for olika test. Det finns en stor risk att dessa merkomplexa delar blir overarbetade och endast kan anvandas vid ett fatal specifika testfall.

• ’nyttofunktioner’, t.ex. enhetligt loggningsforfarande mm.9en wrapper ar ett program (rutin/makro) som kapslar in en annan funktion





9 december 1999

Dock bor det poangteras att utvecklingen av ett ramverk tar tid och resurser. Det skapas inte pa endag utan skall (snarare) utvecklas under en langre tid, for att fa ut maximal nytta i anvandandet av ettramverk.

3.2.3.5 – Forsta personalenDe personer som oftast arbetar pa en testavdelning ar unga och relativt farska programmerare10 somoverlag saknar erfarenheten av systemdesign. Min uppfattning ar att det i en testgrupp bor finnas kunskapinom olika omraden: mjukvaruutveckling och sakkunskap. Dar de med kunskap om mjukvaruutveckling borvara erfarna programmerare och de sakkunniga kompletterar testgruppen som ’duktiga anvandare’, dadessa tenderar att ha andra, vardefulla, angreppssatt an den vanlige testaren. For att detta skall lyckasbehovs det en strategi som inte kraver att alla testare skall vara programmerare samt att det finns enforstaelse hos chefer och ledning att det tar tid att automatisera.

3.2.3.6 – Beakta andra metoder for automatiseringAtt aven anvanda andra metoder och verktyg bor beaktas for att och se hur tester kan utforas utanautotestverktyg. Detta ger insikter i problematiken kring autotestning som kan leda till nya och kanskemer effektiva arbetsmetoder.

3.3 Klassiska misstag och problem

I sin artikel om klassiska testmisstag delar Brian Marick[23] in misstagen i fem olika grupper; testningensroll, planeringen, personal, arbetet och teknologins framfart.

3.3.1 Rollen

Vilken roll ett test har brukar ofta avspegla sig i att folk tror att det ar testarna som garanterar kvalitenhos en produkt. Detta ar en felaktig uppfattning av garantin for en produkts kvalite – alla inblandade iutvecklingen, i alla steg, ar ansvariga for att garantera kvaliten av sitt eget arbete med produkten.

Tester ar inte direkt fokuserade pa kvaliten. De involverar sallan ens uppskattningar om hur mycket felsom finns11 utan koncentreras pa att upptacka sa manga fel som mojligt sa snabbt som mojligt. Marickmenar att det ar battre att veta, med viss osakerhet, ungefar hur manga fel det finns, och var, innanfelsokandet borjar. Vinsten med detta angreppssatt ar att battre tester kan utformas.

I rollen ingar det aven att hitta fel, dock sa anser Marick att det handlar om att hitta de allvarliga felen, dear de som staller till mest problem. Till dessa mer allvarliga fel bor aven problem med anvandarvanlighetenlaggas till eftersom dessa problem inte anses vara felaktigheter - men det ar problem som anvandarna(koparna) ser, vilket enligt min uppfattning darmed maste anses vara av stor vikt for ett foretag.

3.3.2 Planering

Planeringen av tester inriktas ofta mot testning av funktionaliteten del for del. Istallet borde ett test varautformat sa att aven olika delar testas tillsammans och samtidigt, vilket ar sa ett program arbetar naranvandarna kor det. Testerna tenderar aven att utforas i nagon form av ordning, d.v.s. att nasta test intepaborjas forran det foregaende ar klart. Pa detta satt kan fel upptackas for sent (vilket ar kostsamt, specielltstrax innan leverans). Det som bor goras ar att anvanda samma grundtanke som kvaliten i avsnitt 3.3.1vilket skulle ge en god overblick av ’samtliga’ fel istallet for att veta allt om ett fatal.

10enligt Brian Marick[23] ar detta vanligt, da, nar han sjalv, sokte sitt forsta jobb som utvecklare och efter frasen ’we don’tknow much about you yet, so we’ll put you somewhere where you can’t do too much damage’, blev anstalld som testare.

11jamfor med code coverage under 3.2.1


18(62) DEL II: 3. Automatiserad testning3.3 Klassiska misstag och problem



9 december 1999

3.3.3 Personal

En duktig testare behover ha manga fardigheter och kvaliteer, sasom:

• metodisk och systematisk

• taktisk samt diplomatisk

• skeptisk, speciellt mot antaganden och vilja se konkreta bevis

• formaga att kunna upptacka och folja upp sma detaljer

• goda skriv- och talarkunskaper

• intuitiv for det som andra mojligtvis forvantas missforsta

• viljan att forsoka, experimentera, trial-and-error

Bade Kaner[24] och Marick[23] menar pa att manga testare inte uppfyller dessa krav, da de oftast ej harden erfarenheten och kunskapen som behovs. Unga testare ser sitt arbete som en mellanlandning pa vagentill utvecklingsavdelningen. Vissa foretagen tycker kanske att en ’okunnig’ person pa testavdelningen armindre riskfullt an att ha en sadan pa utvecklingen.De personer som ar med i en testgrupp och som inte sysslar med programmering (domanexperter, sakkun-niga, black-box-testare12 etc.) tillfor gruppen bredd och djup sa att gruppens kunskap far mer helhet ochpa sa satt blir battre. God programmeringskunskap maste trots allt alltid finnas i en testgrupp. Dennakunskap ar, i det narmaste, ovarderlig vid felsokning13.

3.3.4 Arbetet

Att ’programmerare inte kan testa sin egen kod’ ar en myt. De testar sin egen kod hela tiden och naturligtnog, finner fel, men inte alla fel. Det ar darfor det behovs oberoende testare. Vid en jamforelse gor godaprogrammerare all funktionell testning och testare gor alla ovriga tester. For att de testfall som skall utforasskall vara betydelsefulla maste testerna prova och undersoka fler delar an bara anvandargranssnitten.Figur 9 illustrerar en schematisk bild av ett program utan nagra tillagg for testning och detta ar envanlig situation; tester skall dels verifiera anvandargranssnittet och dels undersoka applikationens inredelar och struktur. For att mojliggora detta maste det laggas till testtillagg (testpunkter/testingangar)och applikationen bor istallet ha den schematiska uppbyggnaden enligt figur 10.

Figur 9: Schematisk grovfordelning av en applikations innehall [23].

Dock sa ar programmerare inte sa valvilliga att lagga till testkod, de vill inte forstora sin kodstruktur medtestdelar, som anda kommer att lyftas ut ur applikationen till releasen. Men utan denna extra testkodkommer testerna da missa de fel som inte upptrader via interaktion med anvandargranssnittet. En losningpa detta problem ar att anvanda ett verktyg som hjalpmedel och som lagger till denna testkod. Idagfinns det sadana verktyg tillgangliga pa marknaden och som automatiskt lagger till kod som kontrollerarspecifika fel, t.ex. minneshantering.

12Ett black-box-test ar ett test av en produkt utan kunskap om inre struktur och uppbyggnad. Det kan liknas vidforutsattningslos och ostrukturerad funktionstestning[33].

13en programmerare finner med stor sannolikhet talet 2147483648 mer intressant an en en lekman, da det far en heltalsva-riabel att bli for stor (signed integer overflow) pa de flesta av dagens datorer.





9 december 1999

Figur 10: Schematisk grovfordelning av en applikation med testpunkter [23].

Dokumenteringen – ForeEn definition pa ett testfall bor kunna besvara foljande fragor:

• Testkonfiguration: Vilket mjukvaruobjekt testas och vilken testutrustning behovs?

• Testevaluering: Vilken funktion testas av testfallet?

• Testets initialtillstand: I vilket tillstand ar applikationen som testas innan testet paborjas?

• Testsekvensen: Hur utfors testet?

• Testverifikation: Vilken ar testpunkten och hur verifieras resultatet?

• Testets utgangstillstand: I vilket tillstand ar applikationen som testas efter testet? (detta borde varalika som tillstandet innan testet)

Ett testskript bor, minimalt, ha foljande fem delar:

1. Rubrik som beskriver syftet och anvandandet av skriptet.

2. Testinitiering som staller upp samtliga intressanta initialtillstand.

3. Testverifikation som kontrollerar om testet lyckas eller inte, ett s.k. orakel.

4. Testlog med resultatet av genomkorningen.

5. Clean-up som garanterar att applikationen under test ar i ett valdefinierat tillstand, aven om testetmisslyckats.

Om punkterna i de tva senaste upprakningarna ovan alltid anvandes vid framtagning och programmeringav tester sa skulle det, enligt Tilo Linz och Matthias Daigl[25], bli valdigt enkelt att underhalla samt sattaihop testsekvenser. Ateranvandandet ar nagot som Linz/Daigl ser som en mycket viktig del att utnyttja.

Dokumenteringen – EfterNar testarbetet ar klart och ett visst antal fel upptackts kommer testarna in i ett nytt problematisktomrade, att dokumentera felen. Kaner[24] ser har fem olika problem som testaren maste losa:

1. Beskriva hur felet kan aterskapas.

2. Beskriva vad som gick fel (vad borde ha hant? vad som hande egentligen?).

3. Att inte underskatta vikten av felet (vilken prioritet det har, beskriva hur en kund skulle tolka det).

4. Hjalpa programmerarens avlusning genom att forenkla eller utveckla forfarandet som felet uppstodi.

5. Felrapporter kan vara forolampande samt nedsattande och forsamrar darfor relationen mellan ut-vecklare och testare.





9 december 1999

Felrapporteringen ar en av de grundlaggande faktorerna i felhanteringen av och utvecklingen av tester. Detar den som skall fungera som en kontinuerlig kalla av information och kunskap for kommande testuppgifter.Darmed maste rapporteringen skotas pa ett sadant satt att den mojliggor ett underlag innehallandesrelevant och beskrivande information for alla (programmerare, ickeprogrammerare, chefer etc.).

3.3.5 Teknologins framfart stalld mot det ekonomiska faktorerna

Automattester bygger pa en enkel ekonomisk ide:

’Om det kostar X SEK att genomfora ett manuellt test forsta gangen,kommer det att kosta ungefar X SEK varje gang darefter, medan omdet kostar Y SEK att utveckla ett autotest sa kommer alla foljandeautotestkorningar praktiskt taget kosta 0 SEK.’

Y ar alltid storre an X (enligt erfarna experter kan Y ligga mellan 3 till 30 ganger storre an X enligt[23]) men brukar vanligtvis[33] aberopas vara runt 10 ganger storre an X. For att ett autotest skall varalonsamt maste det alltsa anvandas fler an 10 ganger. Trots kunskapen om ekonomin bakom autotestergors det anda autotester som inte kors tillrackligt manga ganger for bli lonsamma. Problemet ligger i attman forsoker gora alla tester till autotester, vilket per definition inte ar lampligt. Det finns ett fatal falldar autotester ar ett maste, t.ex. vid:

1. last-, prestanda- eller stresstester.

2. smoke-tests, gar igenom all grundlaggande funktionalitet efter en storre kompilering14.

3. konfigurationstester, tester pa olika plattformar, hardvara och tredjepartsprodukter (det samma somatt testa den underliggande stodkoden se avsnitt 3.4.2).

3.4 Vilka tester kan automatiseras?

Foljande beslutsprocess foreslas av Brian Marick[26]:

1. Ett automatiserat test som kors en gang kostar mer an att kora ett manuellt test en gang. Hurmycket mer kostar det?

2. Ett autotest har en begransad livstid, inom vilken den maste betala sig. Kommer autotestet att haett varde under hela tiden, eller kommer det att bli oanvandbart? Vilka handelser far testet att blioanvandbart?

3. Under ett autotests livstid; hur troligt ar det att autotestet hittar nagra nya fel, utover de somupptacktes vid forsta korningen? Hur forhaller sig denna osakerhet gentemot kostnaden for en auto-mation?

Ett test som automatiseras kan ses invalidera en viss mangd olika manuella tester. Den avvagning somgors ar saledes att jamfora antalet fel som de manuella testerna tar fram mot det som autotestet hittar,samt hur allvarliga felen ar. Det ar givetvis en stor osakerhet behaftat med antalet och hur allvarliga felenar, men det ar nagot som Kaner tycker ar bland det viktigaste aspekterna i avgorandet om ett test skallautomatiseras eller inte. Antalet fel ar det absoluta vardet av testning och darfor borde automatiska ochmanuella tester aven jamforas i dessa termer. Grunden till detta pastaende harur fran John Dalys regel15

Vilka fel missar jag nar jag gor detta?

14som, enligt Marick[26], kan forbattras genom att anvanda/testa olika vagar genom koden. Detta gors for att testabasfunktionaliteten i olika sekvenser, miljoer etc.

15What bugs aren’t I finding while I’m doing that?


21(62) DEL II: 3. Automatiserad testning3.4 Vilka tester kan automatiseras?



9 december 1999

3.4.1 Autotestets livslangd

Figur 11: Autotestets liv och faser [26].

Figur 11 belyser autotestets ’livscykel’ och for att kunna uppskatta hur lang tid testet kan anvandasmaste kodstrukturens paverkan forklaras. En applikation som ar under test har da en viss specifik del avkoden som amnas undersokas och testas. For att kunna skilja pa direkt och indirekt paverkande koddelari applikationen kan de delas in i foljande tva grupper (se figur 12):

Figur 12: Koden i en applikation; kod under test, mellanliggande kod och testets kodpropagering [26].

• Kod under test, koden vars beteende som testet skall prova.

• Mellanliggande kod, all annan kod mellan kod under test och testet sjalv.

For att oka autotesters varde, d.v.s enklare underhall samt langre livslangd, kapslas autotestverktygensskript in i testbibliotek (ramverk) som filtrerar bort irrelevant information, enligt figur 13. Ramverkettillater, pa detta vis, ett test att exakt specificera vad som behovs i indata, vilket klart forenklar ett testsanvandningsomrade (det blir mer av en datadriven losning).





9 december 1999

Figur 13: Koden i en applikation samt testpunkter och ramverk [26].

3.4.2 Vardet av ett autotest

Nar anvandargranssnittet forandras behover testaren endast kompensera detta i ramverkets biblioteksfunk-tioner (eftersom det troligen finns betydligt mer testkod an ramverkskod blir kostnaden av forandringenbetydligt mindre). Men det ar inte bara det grafiska anvandargranssnittet som genomgar forandringar ut-an aven kod under test och aven dar maste testaren beakta hur stabil den ar vid forandringar. Marick[26]foreslar att aven har gora en uppdelning av kod under test i tva delar:

• funktionskod, koden som implementerar den testbara funktionaliteten hos kod under test och utforde operationer som anvandaren valjer via granssnittet, samt

• stodkod, de delarna av kod under test som inte direkt kan nas och testas, men som anda utnyttjasoch stoder funktionskoden,

dar tester oftast amnar utvardera funktionskoden da stodkoden oftast ar osynlig for testaren (sefigur 14).

Figur 14: Omradet under det horisontella strecket ar stodkoden och omradet ovan illustrerar funk-tionskoden, har med fem specifika funktioner [26].

Figur 14, visar hur funktions- och stodkoden ar relaterade. Det som testaren nu maste ta hansyn till ar hurforandringar i kod under test paverkar vardet av ett autotest. Om det sker en andring i funktionskoden,se figur 15, kommer de autotester, amnade for denna funktion, med stor sannolikhet att ej fungera16.

16De flesta andringarna i funktionskoddelarna ar for att styra beteendet hos en applikation.





9 december 1999

Figur 15: En andring i en funktion har gjorts i kod under test (den morkare delen) [26].

I det andra fallet, nar forandringarna ej direkt ligger i den undersokta funktionskoden (figur 16) kan ettautotest fortsatta att fungera och ha varde. Ty om forandringen i stodkoden stoder de nya delarna ifunktionskoden, men, inte ar applicerbar for de gamla opaverkade funktionsdelarna, da, och endast da,kan autotester amnade for den opaverkade funktionskoden vara av varde. De kan da hitta fel om de korsigen.

Figur 16: Har har tva funktionsdelar andrats och en ytterligare har lagts till. For att dessa nya koddelarskall fungera har aven en viss del av stodkoden andrats/paverkats [26].

Detta resonemang leder till den centrala paradoxen i autotestning, enligt Marick[26]:

’Ett autotests varde ar i flesta fall orelaterad till det specifika syftetsom det skapades for. Det ar de oforutsagelsebara handelserna somraknas: de ovantade fel som testet inte syftar till att hitta’.

Testa ratt delEtt test skrivs inte for att det skall hitta fel, utan for att undersoka om en funktion fungerar pa sadantsatt som specificerats. Nar autotester sedan utvecklas for specifika funktioner, som ar olika for anvandarenmen utnyttjar samma stodkod, kommer dessa tester att alla fungera eller misslyckas. Detta beror pa attur stodkodens perspektiv ar testerna identiska och om det da finns fel i stodkoden kommer de alla attmisslyckas pa samma satt och vis, vilket illustreras i figur 17.

Figur 17: Tre tester, med olika indata och resultat, men som alla anvander sig av samma stodkod[26].





9 december 1999

All stodkod ar inte del av kod under test och vissa delar ligger gomd for vissa specifika tester. Dessa delarkan t.ex. vara minneshantering, narverksdelar, grafikmoduler, databaskod mm. De ar forvisso testbaramen ur funktionskodens perspektiv ar de stora kodblock med sarskilda uppgifter. En reviderad bild avden mycket forenklade figuren i figur 12 kan se ut som den i figur 18.

Figur 18: Kod under test uppdelat i mindre delar med block av stodkod [26].

Svarigheten ligger i hur bade stodkod och interaktionen mellan stodkod och funktionskod kan testasutan att egentligen ha sa mycket kunskap om stodkoden. Ett steg i den riktningen ar att anvanda sigav scenariotester som ar uppbyggda pa sadant satt att de efterliknar anvandare. Ty anvandare anvanderbetydligt fler funktioner, operationer och delar av en applikation an vad ett autotest normalt gor (autotestetar ju oftast amnat for en viss specifik del av koden).

Scenariotester upptacker saledes fel och upptradanden som en vanlig anvandare skulle upptacka. De tvingaraven testare att bete sig som anvandare, vilket da far testarna att upptacka de icke anvandarvanliga,irriterande och frustrerande egenskaperna hos ett program. Dessa egenskaper tillhor de fall dar produkten’upptrader enligt specifikation’, och, specifikationen ar felaktig.





9 december 1999

Del III

NulagesanalysNulagesanalysen gar igenom stora delar av den befintliga tekniken inom det stora telekomomradet ned tillSIM-kort och SMS.

4 Utredning av teknologier

4.1 Telekom

Telekomindustrin har lange utvecklats som en separat del som endast utfor en uppgift ”tvavags rostover-foring i realtid mellan manniskor”. Under de senaste aren har dock utvecklingen naturligt gatt mot data-kommunikation enligt Alriksson[32]. Det ar i dagens system inte mycket som skiljer mellan datakom ochtelekom, forutom att telekom har ett mindre tjansteutbud gentemot sina slutanvandare. Den huvudtjanstsom ett telekomsystem har, att mojliggora telefoni mellan personer, ar robust och utokningar av systemetinriktas oftast mot mobiltelefonioperatorerna, och speciellt drift och underhall.

Operatorerna utvecklar a sin sida nya tjanster som ligger narmare till slutanvandarna och till den aktuellatekniken. Dagens mobiltelefoner haller en ganska jamn niva vad galler ljudkvalite, mottagning, pris, storleko.s.v. Operatorernas mobiltelefonsystem erbjuder aven samma jamna niva, deras system ar kanske intelikadana, men systemen har alla liknande funktioner (t.ex. hanteringen av abonnemang och telefontrafik).

Operatorerna har konkurrerat med priser och kvalite hos kundservice. Enligt min uppfattning kommer desnart ha ytterligare ett utbud att locka kunderna med. Jag tror att tjansteutbudet kommer att bli dennafaktor som far kunderna att valja en viss teleoperator framfor en annan. Darfor tror jag att operatorernablir tvingade ta fram och erbjuda mer tjanster (nytto- och mervardestjanster).

4.2 Mobiltelefoni

4.2.1 GSM Historia(Global System Mobile)

GSM-natets foregangare, NMT-450 och NMT-90017, har funnits i Sverige sedan 1988-89. Detta mobil-telefonnat ar analogt och har fortfarande den basta tackningen, speciellt NMT-450. Detta beror pa attdet behovs fler radiomaster for att tacka upp ett omrade ju hogre barfrekvensen ar. Detta innebar attNMT-450-systemet som kraver farre radiomaster ar billigare att driva och underhalla an ex GSM-1800(GSM bygger pa TDMA, Time Division Multipel Access), som kraver betydligt fler radiomaster.

Den storsta svagheten med NMT ar att det inte finns nagra sakerhetsmekanismer; dels gar det relativtenkelt att lyssna av ett samtal och dels sa gar det att duplicera en NMT-mobiltelefon. Dupliceringen gorsgenom att helt enkelt kopiera abonnemangsinformationen som finns pa ett chip i en telefon och placeradetta pa ett chip i en annan telefon.

4.2.2 Standarder

De nordiska mobiltelefonoperatorerna har sedan starten av NMT och GSM varit en mycket drivande del iutvecklingen och framtagningen av mobiltelefonstandarder. Framfor allt for det digitala mobiltelefonistan-darden for Europa, GSM-standarden, ETSI European Telecommunications Standards Institute. Vilket harlett till att Skandinavien idag anses ha en mycket hog tackning for och anvandning av mobiltelefoner.

17450 respektive 900 MHz


26(62) DEL III: 4. Utredning av teknologier



9 december 1999

4.3 SIM-kort, Subscriber Identity Module

4.3.1 Kort historia

I varje GSM-telefon sitter idag ett SIM-kort vars ursprung kommer ifran 1974 da Roland Moreno uppfann’The Integrated Circuit Chip Card’, ICC-kortet, mer kant som ett smart-card.Av alla smarta kort som tillverkas nufortiden och som ar i cirkulation pa varldsmarknaden anvandsde flesta korten i telekommunikationsindustrin som forbetalda (pre-paid), ateranvandbara telefonkort[11,12]. Dock sa ar det en betydande okning nar det galler anvandningen av intelligenta mikroprocessorkortsom personliga accessenheter for digital mobilkommunikationsnatverk18 och for mer sakerhetskravandeautenticeringar for betalningssystem hos banker och i affarsindustrin.

4.3.2 Modul for en abonnents identitet

Da SIM star for Subscriber Identity Module ar det logiskt att se det som en modul som endast innehallerinformation relaterad till GSM-specifika abonnentidentifikations funktioner. Men, en SIM innehaller ocksaannan information sasom funktioner, applikationer19 och data som inte ar inkluderade i GSM specifika-tionerna.

En abonnents identitet ar inte i ett 1 − 1 forhallande till det fysiska mediumet for atkomst till GSM-natet. Detta medium, MS (Mobile Station mobiltelefon och SIM-kort, se 4.5.1), maste i ett cellnatverkvara associerat med ett abonnemang - sa kallat personaliserat. Ett vanligt satt ar att spara onskadanvandarinformation i ett permanent minne som en ’abonnemangsidentifierare’. Sa fungerar det i de flestaanaloga cellnatverk, men i ett GSM-natverk ar det annorlunda.En MS som skall anvandas i ett GSM-natverk ar uppdelad i tva delar:

1. en del som innehaller hard- och mjukvara for radiogranssnittet, och

2. en del for abonnentspecifika data, SIM.

En stor fordel med denna losning ar att en anvandare har flera olika frekvenser och olika system for attfa tillgang till GSM-natet. Kortet kan aven anvandas for att spara data, sasom telefonbok, SMS (ShortMessage Service), kontoinformation etc.

4.3.3 Teknisk beskrivning

Ett SIM-kort kan i grunden endast utfora fyra renodlade funktioner:

1. Hantering och lagring av information

2. Applikationslogik

3. Autenticering

4. Kryptering och dekryptering

1 – Hantering och lagring av informationData kan antingen lagras en gang i ett lasminne, eller i ett skriv- och lasminne som tillater ett stort menbegransat antal uppdateringar. Denna mojlighet att kunna andra, lagga till, addera och subtrahera datapa ett kort gor det mycket atravart i finansiella system som anvander elektroniska pengar (e-cash).

2 – ApplikationslogikEtt kort kan innehalla flera applikationer och applikationslogiken erbjuder mojligheter att aktivera/de-aktivera en applikation eller att instruera en applikation om utfora vissa specifika funktioner.

18sasom GSM/PCN/PCS, (GSM - Global System for Mobile communications, PCN - Personal Communications Network,PCS - Personal Communication Services)

19En applikation bestar av en mangd sakerhetsmekanismer, filer, data och protokoll, dock inga overforingsprotokoll.


27(62) DEL III: 4. Utredning av teknologier4.3 SIM-kort, Subscriber Identity Module



9 december 1999

3 – AutenticeringDenna funktionen avgor om lagrad data pa kortet skall kunna visas eller andras, vilket gor att kortet intebehover vara uppkopplat for att utfora vissa kontroller (indelade i kategorier efter olika nivaer) och dettagor att privat och publik information kan sparas pa ett och samma kort.

4 – Kryptering och dekrypteringI sin natur maste datakodning och -avkodning ske i en lokal och saker miljo och detta stodjer SIM-kortetda sakerhetskritiska data inte behover overforas fran kortet vilket innebar den hogsta mojliga sakerheten.

4.3.4 Den elektriska karakteristiken

Det finns tva stycken standardiserade matningsspanningar till SIM-kort. Den ena anvander sig av femvolt och den andra utnyttjar bara tre volt. I dagslaget ar det trevoltskorten som ar de vanligaste da deforbrukar mindre energi. De kan aven anvandas i en telefon som opererar med fem volt, fast det omvandagar inte att gora. De logiska och elektriska nivaerna finns definierade, ETSI[18] (5V) och ETSI[19] (3V).I [19] finns aven rekommendationer for hur trevoltstekniken skall kunna arbeta pa fem volt.

4.3.5 Kortkonfiguration

De flesta SIM-kortstillverkarna levererar korten med ett standard operativsystem, OS, pa korten. System-forandringar och systemoptimeringar laggs sedan i E/EEPROM-minnet. De olika minnestyper som ettSIM-kort innehaller representerar en avvagning mellan kostnadsminimering och framtida forbattringar ifunktionaliteten. Figur 19 visar de tre faserna som ett kort, efter det att det tillverkats, kan befinna sig i.

Figur 19: Ett SIM-korts tre olika anvandarfaser [11].

GSM-fasen motsvaras av det vardagliga anvandandet och varje gang kortet ar utan matningsspanning ardet inaktivt. Under sin livstid kan kortet involveras i tre olika administrativa faser:

1. produktion

2. (pre)(re)personalisering

3. distribution

Dessa faser och funktioner kan endast nas och genomforas via specifika administrativa autenticerings-mekanismer. De involverade och ansvariga i administrationsfasen ar tillverkare, utfardare (konfigurering),natleverantor (vid aktivering20 av SIM-kortet i ett GSM-nat) samt slutleverantor (programmering av abon-nemangsdata och distribution till abonnenterna). Nar sedan ett SIM-kort har blivit personaliserat med alltillhorande data for GSM-natoperationer, intrader kortet i GSM-fasen.

20Ett abonnemang kan t.ex. aktiveras vid Point-Of-Sale eller via mobiltelefonanvandaren sjalv eller genom kombinationerav ett par OTA-nedladdningsoperationer.





9 december 1999

MinneskonfigurationerSIM-kort ar utrustade med olika typer av minnen. ROM-typen tillhor vanligen den lagsta nivan dar ettspartanskt OS finns inkluderat. RAM anvands for terminalinteraktiva transaktioner. Sedan utnyttjas avensofistikerade och ateranvandbara EEPROM for permanent lagring av applikationsdata.En annan typ av minne ar flash-minnen som ar mindre (billigare) an EEPROM och mer flexibla anEPROM (dock ej flexiblare an EEPROM) som darfor brukar anvandas vid sma serier och test(pilot)-projekt da mojligheterna att skraddarsy flash-minnen ger en snabbare Time-To-Market. De vanligastekonfigurationerna inkluderar RAM, ROM och EEPROM.

4.3.6 Arkitekturen hos ett SIM-kort

Figur 20: Den overgripande strukturen hos ett SIM-kort [11].

FilerBilden i figur 20 visar den generella strukturen over hur filer ar relationerade med varandra pa ett SIM-kort. Det finns tre olika filtyper och filerna ar organiserade i en hierarkisk struktur. Hogst upp i hierarkinligger en huvudfil MF, Master File, och under den ligger DFs, Dedicated Files, samt EF, Elementary Files,som agerar som kataloger respektive systemfiler21. De kan vara administrations- eller applikationsspecifi-ka. Ett OS hanterar atkomsten till data lagrade i de olika filerna som bestar av ett huvud, som hanterasinternt av kortet, och en kropp (datadel). Informationen i huvudet kan fas genom tre olika kommandonget/response/status vilka da returnerar ger filstruktur och filattribut. Ett fil-ID anvands for att adres-sera och identifiera varje specifik fil och det bestar av tva hexadecimalt kodade bytes. Filidentifikationernafungerar under nedan gallande forutsattningar, som gor att varje fil ar unikt definierad:

• en fil skall tilldelas ett fil-ID nar den skapas

• inga filer under samma foralder skall ha samma fil-ID

• ett barn och dess foralder, direkt eller indirekt hogre upp i hierarkin, kan inte ha samma ID

En dedikerad fil, DF, ar en funktionell gruppering av filer som bestar av sig sjalv och alla de filer sominnehaller denna DF i sin foraldrahierarki och en DF bestar endast av ett huvud. Det finns tre typer av DFdefinierade i ETSI[18] som alla ar direkta barn till MF och kan samexistera pa ett multiapplikationskort22.De vanligaste dedikerade filerna ar:

- DF GSM, innehaller applikationer for GSM.

- DF Telecom, innehaller telekomspecifika parametrar och funktioner.21I en analogi med operativsystemet Windows NT kan MF motsvaras av (roten) c:\, DF av en katalog, t.ex. windows,

och en EF av en datafil, t.ex. config.sys, se figur 21.22Vissa kort, (t.ex. GSM och Iridium) stodjer flera olika tjanster och kallas multiapplikationskort.





9 december 1999

En elementarfil, EF, bestar av bade kropp och huvud och finns i tre olika strukturer:

• Transparenta EF, bestar av en sekvens med bytes som refereras med en relativ adress (offset). Denforsta har den relativa adressen 00XX och den totala langden (XX, 0-256 bytes) av kroppens datafinns i huvudet.

• Linjart fixa EF, bestar av en sekvens av poster dar alla har samma (fixa) storlek och langden ochden totala storleken (langd ∗ antal poster) finns i huvudet. Det finns atta olika satt att na dessadessa filer. Den maximala langden ar 255 poster a 255 bytes var. Exempel pa en linjart fix fil arAbbreviated Dialing Number, ADN-filen, som innehaller telefonboken.

• Cykliska EF, anvands for att spara poster i kronologisk ordning och bestar av ett fix antal postermed samma fixa langd samt en lank mellan den sista och den forsta (en cyklisk enkellankad lista) iden forsta posten ar alltid den senast uppdaterade. Exempel pa en cyklisk EF ar filen med senastslagna nummer, Last Number Dialed, LND.

Figur 21: Exempel pa filstrukturen hos ett SIM-kort.

Metoder for filatkomstVarje EF har ett eget specifikt atkomstvillkor for varje kommando. For att kunna anvanda filen masteanvandaren uppfylla villkoret, exempelvis svara med PIN-koden (Personal Identification Mumber). Dessavillkor ar indelade i 15 olika nivaer. IMSI-filen (International Mobile Subscriber Identity) anvandaridentitetenhar niva 15 och telefonboken, ADN, har niva 1. Vid OTA-meddelanden anvands inte dessa atkomstvillkorenda dessa meddelanden anvander sig av en OTA-nyckel istallet (se 4.4.3). Beroende pa SIM-kortstillverkareanvands olika kodningar och de vanligaste ar DES och XOR23.

SIM lagringsforeskrifterSIM-kort skall erbjuda lagringsmojligheter for ett stort antal delar, med vissa sakerhetsaspekter definieradei GSM 02.11[14]. Enligt ETSIs sakerhetskrav skall aven ett SIM-kort hantera och lagra bland annat:

• Fasidentifiering

• PIN, Personal Identification Mumber

• PIN aktiv/inaktiv indikator

• PUK, Personal Unblocking Key

• PIN och PUK felraknare

• En verifieringsnyckel for abonnemanget

Utover denna obligatoriska informationen kan SIM-kortet aven innehalla:

• PLMN valjare Public Land Mobile Network GSM-natverk[14]

• MSISDN nummer, Mobile Station international ISDN Number

• Senaste slagna numret[13]23DES, Data Encryption Standard, krypteringsalgoritm. XOR ar den Boolska logiska funktionen ’exklusivt eller’.





9 december 1999

• Parametrar for bararkapaciteten associerade med olika telefonnummer

• SM och tillhorande parametrar[17]

• Samtalsmatare[15]. Nar denna tjanst aktiveras gar samtliga inslagna telefonnummer och kontroll-nummer via SIM-kortet, som tillater, sparrar eller modifierar numren.

Lokaliseringsinformation, krypteringsnyckel och krypteringsnyckelns sekvensnummer skall alla uppdateraspa SIM-kortet vid varje avslutat samtal och nar MS (telefonen och kortet) ar korrekt deaktiverad enligttillverkarens instruktioner.

4.3.7 Funktionalitet

Funktionaliteten hos en mobiltelefon bestams av vilken fas, enligt ETSI standarderna, som implementeratssamt olika industristandarder. Dagens mest vanliga faser ar, 1, 2 och 2+, dar fas 2 och uppat ar dual-band -kompatibla. Kraven uppstallda i GSM (ETSI) kan vara obligatoriska eller valfria och av detta foljervissa svarigheter att jamfora komponenter i olika faser.

SakerhetenPa samma satt som mobiltelefoner utvecklas och forbattras genomgar aven funktionerna pa SIM-korten enliknande utveckling. Kommandon utover dem som finns specificerade i ETSI[18] tillats endast exekverasom de inte paverkar den ursprungliga funktionaliteten. Aktiviteter som lasning och uppdatering av SIM-data skall kontrolleras for atkomstbehorighet innan de utfors. Alla mojliga atgarder skall vidtagas for attforsakra att inte algoritmer (A3, A824) och anvandarautenticering (Ki) skall kunna bli lasta, andrade,manipulerade eller pa nagot annat satt kringgas for att avsloja hemlig information. Alla MS-processer somkraver anvandandet av Ki skall utforas internt av SIM-kortet. ETSI specificerar inte sakerhetsparametrarnai den administrativa fasen, men atgarder skall alltid tas for att skydda hemlig anvandar och abonnentrela-terad information.Det finns ett flertal forslag for icke-GSM applikationer som delar de gemensamma komponenterna i GSM-systemet sasom banktransaktioner, transporter, e-cash och digitala signaturer. Dessa applikationer kravermer minne pa SIM-kortet och aven viss okning i (SIM-)processorkraft.

AnvandarvanlighetenAEPO, The Association of European PCN Operators25 utfardar specifikationer for minimumfunktionalitetmellan handenheter och skall forsakra att alla PCN-handenheter ar kompatibla med alla PCN-operatorersnatverk26. For att utoka och stodja DCS180027 tog AEPO pa sig att ta fram en mangd utokade specifika-tioner som gar under namnet Common PCN Handset Specifications, CPHS, med ett antal grundlaggandemalsattningar, vilka de mest intressanta ar:

1. Manniska-maskingranssnittet, HMI Human Machine Interface, skall vara enkelt att anvanda, intui-tivt, entydigt och latt att lara sig. Det skall vara utformat sa att anvandaren utan storre fordrojningkan valja telefonfinesser och natverkstjanster med ett minimum av utbildning. Antalet knapptryck-ningar for att fa tillgang till en tjanst eller funktion skall vara sa fa som mojligt. Anvandaren skallhelst inte behova memorera komplexa sekvenser.

2. Nar det ar mojligt skall alla gemensamma operationer over de olika natverken, GSM 900/1800/1900,vara utformade for att forenkla utrustningens design och ge ekonomiska fordelar vid tillverkning.

3. En minimal mangd av vanliga tjanster, karntjanster, skall stodjas av majoriteten av natverks-operatorer. En anvandare som brukar en CPHS-handenhet skall kunna fa tillgang till alla dessakarntjanster pa ett konsistent satt oberoende av det natverk som anvandaren ar kopplad till.

24De algoritmer som anvands av ett SIM-kort kallas for: A3 (Algorithm 3) autenticerings algoritm, A5 (Algoritm 5) kryp-tering/dekryptering, A8 (Algoritm 8), krypteringsnyckelgenerering. De nycklar som anvands benamns: Kc kryptografnyckel(anvands av A5), Ki nyckel for abonnentautenticiering (A3 & A5).

25AEPO, som bestar av de stora mobiloperatorerna i Europa, bildades 1989 och stods av ETSI och DCS1800.26PCN, Personal Communications Network, hit hor aven GSM-natverken 900/1800.27DCS, Digital Cellular System ar ett ’finare’ ord for GSM1800.





9 december 1999

4. Det skall vara mojligt att definiera en delmangd av karntjansterna pa ett SIM-kort for att personali-sera en anvandares abonnemang. Tekniken beskriven i CPHS bor anvandas sa att anvandaren kan fadenna ’personalisering’ i en godtycklig CPHS-handenhet som accepterar kompatibla SIM-storlekar.

4.3.8 SIM Application Toolkit

SIM Application Toolkit, SAT, tillgodoser mekanismer for att lata applikationer pa kortet interagera meden mobiltelefon i fas 2, d.v.s en telefon som stodjer de specifika mekanismerna vilka applikationen behoveroch samtidigt sakrar konfidentiella aspekter och integriteten.Med SAT kan operatorerna erbjuda en helt ny typ av operatorsspecifika tjanster, s.k. SIM-mervardes-tjanster. SAT bestar av en uppsattning verktyg som olika applikationer pa SIM-kortet kan anvanda ochdetta ger SIM-kortet helt nya mojligheter att styra telefonen. Applikationerna, funktionerna, tjansterna arinte specificerade utan det ar upp till operatoren, SIM-kortstillverkarna, mjukvaruutvecklingsklienter m.fl.att gora detta. SAT mojliggor tillagg av nya SIM-baserade applikationer utan att modifiera handenhetenoch utan att behova uppdatera telefonen eller kortet.

SAT-mekanismernaETSI[20] delar in funktionerna for SAT i tre klasser, dar varje klass representerar ett visst antal funktioner.Mobiltelefoner som stodjer SAT behover inte stodja alla funktioner, men skall stodja allt inom sin klass.De tva viktigaste delarna ar Profilnedladdning och Proaktivt SIM.

• ProfilnedladdningProfilnedladdning ar en mekanism i mobiltelefonen for att beratta for SIM-kortet vad den kan.Mobiltelefonen vet i sin tur vad SIM kan via innehallet i tva filer pa kortet (Service Table ochEF-fas).

• Proaktiva SIMETSI[18] definierar att mobiltelefonen skall kommunicera med protokollet SIM T=0, (ISO/IEC 7816-3). Mobiltelefonen ar alltid master och initierar kommunikationen med SIM-kortet och darfor finnsdet inget direkt satt for kortet att initiera kommunikation med ME. Detta minskar mojligheterna attkunna introducera nya SIM-funktioner som behover telefonen, da denna i forvag maste veta vilkaatgarder som den skall gora. Proaktiva SIM kan dock via ett statussvar initiera kommunikation medME. Nagra operationer som ett proaktivt SIM-kort kan initiera ar t.ex.:

– Visa text.

– Sanda ett SM som svar pa en forfragan fran en annan mobil enhet (praktiskt vid t.ex. mobile-handel).

– Initiera en dialog med anvandaren. Via en mangd olika menyer och menyval kan anvandarenkommunicera med ett proaktivt SIM.

Kommunikationen mellan SAT och telefonenFor att en SAT-applikation skall kunna interagera med mobiltelefonen finns det tre stycken kommandonsom kan skickas till kortet fran telefonen.

1. envelope - Detta kommando anvands for att overfora SAT-data till kortet.

2. fetch - Nar ett SAT-kommando skall skickas till ME anvands denna funktion. Langden pa SAT-kommandot som skall skickas kan telefonen fa via ett envelope-kommando.

3. terminal response - anvands for att overfora ett svar till en SAT-applikation som tidigare hamtat(fetched) en SAT-funktion, t.ex. ett menyval.

Figur 22 illustrerar forloppet nar ett inkommande Short Message Service, SMS, mottages av natverket viatelefonen, och flodet nar SIM-kortet behandlar meddelandet och genererar ett kommando som telefonenskall utfora. Efter att envelope har utforts ar det upp till den nedladdade SAT-applikationen att ta nastasteg. I exemplet, figur 22, vill applikationen att mobiltelefonen skall hamta ett kommando fran kortet.





9 december 1999

Figur 22: Handelseforloppet for ett SMS for SIM-uppdatering. Env. = envelope, XX indikerarlangden pa kommandot som skall hamtas. ETSI[18].





9 december 1999

Kortet svarar da med att returnera statusmeddelandet ’91XX’, dar XX ar antalet bytes som skall hamtas.Darefter skickar telefonen fetch till SIM-kortet och laser XX stycken bytes i svaret. Telefonen exekverarkommandot och som bekraftelse pa att kommandot lyckades skickar telefonen terminal response, someventuellt kan innehalla ett resultat i form av ett menyval. Detta forfarande, med att hamta och exekverafortsatter tills kortet som svarar med OK ’9000’.

4.4 Short Message Service, SMS

Med SMS kan meddelanden med en begransad storlek skickas till och fran mobiltelefoner. For att dettaskall vara mojligt kravs ett Short Message Service Center, SMS-C se avsnitt 4.5.1, som agerar som enrelafunktion for SM mellan ett GSM Public Land Mobile Network (PLMN) och mobiltelefonen. ETSI[17]definierar tva satt att, punkt-till-punkt, skicka SMS; Mobilt utfardade och Mobilt terminerande28.

• Mobilt utfardade meddelandenDessa meddelanden, MO (Mobile Originated), transporteras fran telefonen till ett SMS-C och kanvara destinerade till mobilanvandare eller en abonnent pa ett fast telenat.

• Mobilt terminerande meddelandenMobilt terminerande, MT (Mobile Terminated) meddelanden transporteras i sin tur fran ett SMS-Ctill en mobiltelefon och dessa kan komma ifran en annan mobilanvandare (MO) eller fran en mangdolika kallor (e-post, telex, fax, mjukvaruapplikationer).

4.4.1 Strukturen hos ett SM

Ett SM bestar i huvudsak av tva delar:

1. ett datahuvud, som max ar 37 bytes (35 bytes + 2 bytes i datadelslangd) vid nedladdning pa kortet,

2. och en datadel pa maximalt 140 bytes

och totalt ar ett meddelande maximalt 177 bytes lang.

MeddelandetyperDet finns sex stycken olika (Short Message Service) SMS-typer, mellan en MS och ett SC, Service Centre.

Typ Riktning mellan ett SC och MS

sms-deliver SC −→ MS

sms-deliver SC ←− MS

sms-status-report SC −→ MS

sms-status-report SC ←− MS

sms-submit SC −→ MS

sms-submit-report SC ←− MS

Tabell 3: SMS-typer.

28MO, Mobile Originated och MT, Mobile Terminated.


34(62) DEL III: 4. Utredning av teknologier4.4 Short Message Service, SMS



9 december 1999

SMS-huvudFigur 23 visar ett innehallet pa ett SM som en mobiltelefon kan ta emot. Huvudet i ett SMS kallas dendel som ar 35 bytes lang. Dar finns flaggor, adresser, tidsstampling, kodning mm.

35 bytes︷︸︸︷

SMSH︸︷︷︸

1 bytes

SCA︸︷︷︸

2...12 bytes

SMSD︸︷︷︸

1 bytes

OA︸︷︷︸

2...12 bytes

PID︸︷︷︸

1 bytes

DCS︸︷︷︸

1 bytes

SCTS︸︷︷︸

7 bytes

User data︸︷︷︸

2 bytes+140 bytes︸︷︷︸

177 bytes

Figur 23: Uppbyggnaden hos ett SM

1. SMSH Internt SMS-huvud som indikerar statusen pa meddelandet.

2. SCA Service Center Address, vilket SMS-C som formedlade meddelandet. Servicecenteradresserbestar av L + F + N , dar:L ar langden i bytes pa telefonnumret plus FF ar flaggor for nummertyp (TON, Type Of Number) och nummerstruktur (NPI, Numbering Iden-tification Plan)N ar telefonnumret i ett hexadecimalt nibble-switched format29.

3. SMSD Intern statusdata, bl.a. med information om det finns flera meddelande (lankade), sta-tussvarindikator och en replypath.

4. OA Orginating Address. Innehaller adressen (oftast telefonnumret) till utfardaren av meddelandetoch denna adress anvands vid exempelvis vid ett svar pa meddelandet. Utfardaradresser, OA, bestaraven de av L + F + N , men har har langden en annan betydelse da den endast bestar av antaletsiffror i telefonnumret.

5. PID Protocol Identifier, anvands mellan protkollagren (se 4.5.2).

6. DCS Data Coding Scheme, vilken kodning som anvandardatat ar kodat i, beror pa vilken datatypdet ar 7/8/16-bitars SM enligt 4.4.2.

7. SCTS Service Centre Time Stamp. Varje SM har en tidsstampling som vissa GSM-systemdelar (allaService Centers i fig 24) anvander sig av for att avgora statusen pa meddelandet, d.v.s. om detfortfarande ar giltigt, om det da kanske skall raderas eller inte.

8. User Data bestar av 2 bytes for langden plus datat sjalv.

Vart att notera ar de olika satten som adresser hanteras. OA, utfardaradressen och SCA, adressen for ettservicecenter har en del som skiljer sig. Det ar langden, som for den ena ar antalet siffror i telefonnumretoch for den andra ar langden pa hela telefonnumret inklusive utfyllnadstecken. Varfor det ar sa forklarasinte i ETSI[17, 16] som tar upp en del historia och hur adresser skall kodas30.

Vidare har ett SM alltid en validitetsperiod. Denna finns ej i exemplet i figur 23, da endast vaxlar (MSC,Mobile Switching Centre) och SC anvander sig av validitetsperioden vid overforingen av de olika SMS-typerna i tabell 3.

29Mitt mobiltelefonnummer, +46707477234, blir nibble-switched 6407477732F4, dar F ar en utfyllning vid ojamnt antalsiffror i telefonnumret. Plusteckenindikeringen satts i TON

30En mojlighet ar att en adress misstolkades i en specifikation och efter det att denna specifikation implementeratsupptacktes felet men da i ett forsenat stadium.


35(62) DEL III: 4. Utredning av teknologier4.4 Short Message Service, SMS



9 december 1999

4.4.2 Anvandardatat i ett SM

Anvandardatat, User data i figur 23, kan vara en utav tre typer, 7-bitars, 8-bitars eller 16-bitars (Unicode).

7-bitars dataDenna typ av SM ar den vanligaste typen. Alla SM har en maximal langd for anvandardatat pa 140 bytesoch nar meddelandet ar komprimerat till 7-bitars blir det da 160 tecken som kan anvandas for meddelandeoch det ar denna typ som den vanlige mobiltelefonanvandaren forknippar med SMS.

8-bitars dataVid 8-bitars data komprimeras ingenting och denna typ anvands vid av OTA- eller SAT-meddelanden.

16-bitars dataUnicode anvands i Asien dar de behover 16 bitar for att kunna representera alla asiatiska spraks olikatecken. Nar det anvands 16 bitar till teckenrepresentationen blir foljden att endast 70 tecken langa SMkan skickas.

4.4.3 OTA-SM

I 4.4.2 namndes att ett OTA-SM ar ett 8-bitars SM, det som bor tillaggas ar att det ar ett 8-bitars medvissa speciella egenskaper. Nar mobiltelefonen har uppdaterat SMS-filen pa SIM-kortet med ett OTA-meddelande reagerar kortets operativsystem som verifierar att nedladdningen ar tillaten. Detta sker genomatt operativsystemet laser en i en speciell fil pa kortet. Denna fil innehaller en nyckel som mojliggor foroperativsystemet att kontrollera att utfardaren av OTA-nedladdningen ar auktoriserad. Nar detta ar gjorttar operativsystemet och exekverar kommandona i meddelandet.

4.5 Natverksuppbyggnad

Figur 24 innehaller de systemdelar som involveras i overforingen av meddelanden mellan en mobiltelefonmed SIM-kort, MS Mobile Station, och en SME, Short Message Entity.

Figur 24: Den generella strukturen pa SMS-enheter. SMS-GMSC anvands vid MT-meddelanden(SMS-C −→ mobiltelefon) och SMS-IWMSC anvands vid MO-meddelanden (mobiltelefon−→ SMS-C) ETSI[18].

4.5.1 SMS-overforingens primitiver

MS, Mobile Station, ar benamningen pa en mobiltelefon och ett SIM-kort sett som en entitet; vilket arden yttersta komponenten i SMS-overforingskedjan.


36(62) DEL III: 4. Utredning av teknologier4.5 Natverksuppbyggnad



9 december 1999

Short Message Entity, SMEVem, eller vad, som initierar ett SM faller utanfor GSM-specifikationerna, forutom om det ar utfardatfran mobiltelefonen (MO se avsnitt 4.4) d.v.s. en telefon som initierar en sandning. SME, Short MessageEntity, kallas de delar som ar kopplade till GSM-natet, pa ett eller annat satt, och som kan utfarda ochskicka SMS.

Home Location Register, HLRI detta register, HLR, finns specifik information om abonnemangen sparade. Informationen bestar avflaggor och adresser till Servicecenters med olevererade meddelande sparade. Ur ett meddelandeperspektivfinns det en flagga som ar av intresse som indikerar om det finns fler meddelanden som vantar MWD,Message Waiting Data), innehallet illustreras i figur 25.

Figur 25: MWD: De intressanta delarna i HLR ur ett SMS-perspektiv.

• ms-isdn-alert

For att kunna skicka larmmeddelande till alla SC som har forsokt skicka SM till en MS finns det iHLR en flagga, MS-ISDN-ALERT, tillsammans med referenser till de respektive SMS-C-adresserna.Flaggan anvands for att meddela skalet till felet i leveransen.

• mnrf, Mobile-Not-Reachable-Flaganvands for att indikera att telefonen ar ej nabar for natet och detta sparas aven i VLR (VistorLocation Register).

• mcef, Mobile-Station-memory-Capacity-Exceeded-Flagsatts nar minnesutrymmet for SMS pa kortet ar fullt.

• mnrr, Mobile-Station-NotReachable-Reasoninnehaller skalet for att mobiltelefonen ej var nabar nar ett forsok att skicka ett meddelande utforts.

MSC - VaxelnNar ett MSC, Mobile Switching Centre31 tar emot meddelanden fran SMS-GMSC (gateway) ansvarar detfor foljande:

• Mottagning av meddelandet

• Vidarebefordranden av bekraftelser (ackar) fran MS till SMS-GMSC.

• Hamta information fran VLR (Visitor Location Register), sasom det aktuella omradets adress ochnar fel uppkommer hamta relaterad felinformation.

- Om all information fran VLR indikerar att det ar ’OK’ skickas meddelandet till MS och en rapportsands till SMS-GMSC.Annars skapas och sands en felrapport till SMS-GMSC.

31Kallas ibland aven Mobile-services Switching Centre.





9 december 1999

SMS Service Center, SMS-CEtt SMS-C ar oftast hopkopplat med flera olika PLMN32 (GSM-natverk) och kan aven vara sammankopplatmed flera olika MSC, Mobile Switching Centers, inom ett och samma PLMN. Dess uppgift ar att ta emotSM fran olika SME och vidarebefordra meddelanden till den vaxel (MSC) som mottagaren ar koppladtill. Ett SMS-C ar aven ansvarig for att tillse notifieringar till utfardaren om det skickade meddelandetsaktuella status. I dagslaget finns det sex stycken olika protokoll for SMS-C (se tabell 4) och det har blivitsa manga darfor olika tillverkare anvander olika standarder. For att adressera ett SMS-C anvands oftastett PLMN-nummer.

Tillverkare Transportprotokoll Applikationsprotokoll

SEMA TCP/IP & X.25 UCP & OISCMG 2.1/3.0 TCP/IP & X.25 UCPAldiscon TCP/IP & X.25 SMPPNokia TCP/IP CIMD2Cap X.25 Cap sogettiMXE/Ericsson TCP/IP CAP II

Tabell 4: Protokoll for kommunikation med ett SMS-C och respektive tillverkare.

SMS-C behaller ansvaret och sparar meddelandet lokalt tills en statusrapport kommer in, eller tills giltig-hetsperioden gatt ut.Exempel pa trafikflode mellan MS och SMS-C.

• SMS-C −→ MSEtt SMS-C skickar ett SM till en Gateway (SMS-GMSC) som fragar HLR om nodvandig routingin-formation for att kunna vidarebefordra meddelandet. Darefter skickas det vidare, ibland over olikanatverk (PLMN), till aktuell MSC som telefonen ar uppkopplad mot.

• SMS-C ←− MSMobiltelefonen skickar ett meddelande till narmaste MSC och i meddelandet finns en adress33 till ettSMS-C. Om anvandaren befinner sig i ett PLMN som inte tillhor mobiloperatorsleverantoren kommerdet besokta natverket att routa meddelandet till lamplig SMS-IWMSC (SMS InternetWorking MSC)i det adresserade SMS-C-natverket.

SMS Gateway MSC, SMS-GMSCI figur 24 indikeras att denna gateway, SMS-GMSC, hanterar trafiken till en MS och vid ett inkommandemeddelande ansvarar SMS-GMSC for foljande operationer:

• mottagning av meddelandet

• Parameterinspektion.Om nagon parameter ar felaktig returneras lampligt felinformation till SMS-C i en felrapport.Om alla parametrar ar ’OK’ konsulteras HLR for routinginformation (eller mojlig felinformation).

• Om allt ar ’OK’ vidarebefordrar SMS-GMSC meddelandet vidare till MSC, skickar en rapport tillSMS-C och notifierar HLR om den lyckade sandningen.

• Om det blev fel under sandningen informeras HLR om skalet till felet och skickar en felrapport tillSMS-C. Om MS var icke-nabar satts MNRF, i HLR dar aven adressen, till det SC som skickademeddelandet till SMS-GMSC, sparas.

I vissa falla brukar MSC och SMS-GMSC vara en och samma enhet.32PLMN - Public Land Mobile Network33oftast ett telefonnummer, en sa kallad E.164-adress.





9 december 1999

SMS InternetWorking MSC, SMS-IWMSCDetta vaxelcenter fungerar pa samma satt som SMS-GMSC med skillnaden att trafikens riknting gar imotsatt rikting, d.v.s. fran en MS till ett SMS-C.

4.5.2 Protokollagren i SMS-miljon

Enligt ETSI finns det fyra olika protokollager i SMS-overforingen. Figur 26 visar vilka lager som de olikaSMS-primitiverna anvander sig av.

Figur 26: Protokollagren for Short Message Services. Bilden kommer fran ETSI[17].

SM-AL – Short Message Application LayerDetta lager, applikationslagret, anvands av SIM-applikationer och skapar ett granssnitt for att kommuni-cera via portar (likande portar for TCP/UDP i TCP/IP-natverk).

SM-TL – Short Message Transport LayerSM-TL, transportlagret, fungerar som en tjanst at applikationslagret. Detta mojliggor att SM-AL kanoverfora (och ta emot) meddelanden till (och fran) sin ’mottagande motsvarighet’ 34. For att halla ordningenpa meddelanden och rapporter mellan lagren finns det primitiver i SM-AL & SM-TL som innehaller enidentifierare, SMI (Short Message Identifier). Denna identifierare mappas sedan mellan relalagret ochtransportlagret35.

SM-RL – Short Message Relay LayerDetta relalager, SM-RL, ar en relatjanst at transportlagret som anvander det till att skicka dataenheter,TPDU (Transfer Protocol Data Units), till sin mottagande motsvarighet. Aven i detta lager finns det enSMI, men denna foljer med meddelandet mellan ett SC och en vaxel (SMS-GMSC/SMS-IWMSC).

SM-LL – Short Message Lower LayerDet finns inga obligatoriska protokoll mellan ett SC och ett MSC under SM-RL specificerade enligt GSM.Detta ar en overenskommelse mellan SMS-C- och PLMN-operatorerna[11], vilket ar forklaringen till attdet finns ett antal olika s.k. SMS-C-protokoll, se tabell 4.

34engelska peer entity35SMI foljer inte med meddelandet till nasta lagre niva utan finns bara mellan tva narliggande lager. Darfor kan ett

meddelande ha olika identifierare pa MS och SMS-C sidorna.





9 december 1999

4.6 AviSIM OTA Service center

AviSIM OTA Service Centre (OTA-SC), [3], ar en plattform som innehaller alla mervardestjanster baseradepa OTA-tjanster.

AU-Systems designmal har varit att skapa ett flexibelt, oppet och modulariserat system. Arkitekturen arbyggd pa en stabil (C++) plattform for transaktionstjanster av karaktaren mission-critical [9]. I bottenligger ett ramverk (se aven 6.1.1) utvecklat i C++. Ramverket innehaller klasser for kommunikation,tradning mm. och samtliga intressanta primitiver for de SMS-typer och SIM-kort som AU-System Mobilestodjer. Applikationer utvecklade med detta ramverk kan koras pa Windows (3.0/95/NT) och UNIX(Solaris/HP) vilket jag anser gora systemet med dess tillhorande applikationer till ett flexibelt system.

Den modulara designen mojliggor integration med Customer Care Systems (CCS), Billing Systems (BS)och personaliseringssystem saval som med SMS-C, SIM-kort och ovriga GSM-delar. Den oppnar ocksadorrarna for SIM-kortstillverkare och tredjepartsleverantorer att utveckla egna produkter ovanpa AviSIMOTA-SC-plattformen. Med SMS som informationsbarare blir tekniken bred och stodjer darmed OTA-losningar for olika kortleverantorer.

4.6.1 Systemarkitekturen hos AviSIM OTA-SC

Klientapplikationerna (klienttjansterna) stods av ett flertal olika servrar som arbetar under klienterna.Generellt har en applikation en motsvarande server. For att kommunicera med systemet kan olika appli-kationsgranssnitt anvandas (sasom C++ API[10]) eller en dedikerad applikation. I grundutforandet harAviSIM OTA-SC tre stycken servrar och till detta kan tre stycken andra laggas till. Figur 27 illustrerarde underliggande systemkomponenterna i arkitekturen hos OTA-SC.

Figur 27: Systemarkitekturen hos AviSIM OTA-SC [3].

OTA-servernOTA-servern, (aven benamd SIM File Management, SFM-servern), kommunicerar med alla applikationersom anvander OTA-meddelanden (se avsnitt 4.4.3) for att uppdatera informationen pa ett SIM-kort. Viden meddelandeoverforing fran en klient gors en kontroll med Databasservern att meddelandet ar giltigt.Nar information om ett SIM-kort skall tas fram hamtas denna ifran databasen som ar samstalld medinnehallet pa SIM-kortet.


40(62) DEL III: 4. Utredning av teknologier4.6 AviSIM OTA Service center



9 december 1999

WSM-servernWSM, Wireless Service Management, har samma funktion[4] som OTA-servern, fast den hanterar SAT-meddelanden (aven benamt SIM Toolkit Messaging, STM) istallet, se avsnitt 4.3.8.

TransportservernTransportservern (TS) arbetar med olika typer av in- och utgaende meddelanden (requests) mellan klien-terna och servrarna. Den fungerar som den centrala fordelaren i AviSIM OTA-SC-systemet[8]. Alla med-delandeoverforingar transformeras i TS till SM (Short Message) enligt motsvarande SMS-C-protokoll36.For att TS skall kunna skapa ett korrekt SM fragar den databasen om destinationskortets aktuella status.Det som TS behover veta ar bl.a. vilket innehall som finns pa kortet och t.ex. hur mycket minne det finnskvar. Darefter skickas det hopsatta meddelandet till ett SMS-C. Varje gang som det sker en nedladdningpa kortet gors ocksa en uppdatering i databasen efter det att en bekraftelse mottagits fran SMS-C. Pa savis kommer innehallet pa kortet och det i databasen ’alltid’ att vara lika.

DatabasservernDatabasen ar, utover Transportservern, en mycket central del i OTA-SC-systemet och innehaller foljandeinformation och data:

1. Information om alla OTA-meddelanden och de SM som de genererat. Detta inkluderar statusen forvarje OTA-request, utfardare och destination. Denna information sparas med statusen for varje SM.

2. Innehallet av varje SIM-kort (d.v.s. SIM-data och applikationer). All information finns i databasensom en spegling av kortets innehall som kan anvandas av applikationer for att se vad som finns pakortet.

3. Anvandarprofiler och anvandaraccessprofiler. Det ar en hierarkiskt indelning av anvandarprofiler ochanvandarrattigheter som kan definieras for en mangd olika korttyper ned till specifika (enskilda) kort.

Databasen ar framst kopplad mot Transportservern vilket betyder att alla uppdateringar pa ett visst kortbor ga via en Transportserver.

4.6.2 Klienttjanster – Applikationer

OTA-SC, se figur 28, bestar i dagslaget av sju stycken klienttjanster37 dar tre stycken finns med igrundutforandet och utformar basfunktionaliteten.

Figur 28: AviSIM OTA Service Centre med samtliga klienttjanster [3].

36AviSIM OTA SC stodjer samtliga protokoll i tabell 4.37Som parentes kan namnas tva stycken verktyg som AU-System utvecklat for verifiering av innehallet pa SIM-kort, dessa

ar AviSIM Toolbox[6] och AviSIMPOS[7].


41(62) DEL III: 4. Utredning av teknologier4.6 AviSIM OTA Service center



9 december 1999

Drift och underhallMed tjansten Operation and maintenance kan en operator utfora felsokning och analyser pa sin OTA-server. Applikationen visar loggar, alarmhandelser och skoter databashanteringen. Samtliga larmhandelserkan ocksa nas via SNMP (Simple Network Management Protocol).

Administration av anvandare & SIM-kortDet finns ett stort antal administrativa funktioner och tjanster for SIM-korten som ett OTA-SC hanteraroch nagra av tjansterna i User and SIM administration ar:

• Hamta och visa anvandar- eller SIM-information.

• Andra eller lagga till SIM-data.

• Administrera (operatorens) anvandarprofiler. Alla som anvander OTA-SC behover inte kunna utforaalla funktioner och tjanster och detta regleras m.h.a dessa anvandarprofiler, enligt informationen iDatabasservern, se avsnitt Databasservern under 4.6.1.

SMS-tjansterShort Message Services mojliggor en atkomst pa lagniva till SMS-funktionen i Transportservern och ettSMS-C. Det anvands for att skicka och ta emot SM. Skalet till att just SMS anvands ar darfor att samtligamobiltelefoner stodjer SMS och det ar just nu det enklaste sattet att overfora data till en mobiltelefon.

4.7 Framtiden

Detta avsnitt behandlar aspekter kring hur framtiden kan komma att utvecklas. Dessa aspekter framkomvid ett oppet samtal med Per Lundh, Marknadschef pa Across Wireless AB, tidigare AU-System Mobile.

4.7.1 Standarder

Det europeiska standardiseringsorganet, ETSI, haller pa att ta fram den tredje generationens mobilte-lefonistandard, UMTS, Universal Mobile Telecommunication System. UMTS omfattar bl.a. W-CDMA(Wideband-Code Division Multiple Access), och kommer enligt ETSIs planer att anvandas mellan 2000-2005. UMTS syftar till att mota de behov som de kommande teknologierna har. Malet ar att kunna klaraav mycket hoga datahastighter som kan hantera rost-, audio och videodata. Utformningen av UMTS gorETSI i samarbete med det varldsomfattande standardiseringsorganet International TelecommunicationUnion, ITU.

4.7.2 GPRS

GPRS-teknologin (General Packet Radio Service) ar en paketformedlande tjanst som ETSI tog fram idecember 1997 och ar en av de viktigaste delarna i overgangen till den tredje generationens mobilkommu-nikation - det mobila Internet.Som ny teknologi pa vag att foras in pa marknaden star GPRS infor ett flertal problem dar natplaneringenar den storsta. Inforandet av GPRS kommer att ta tid, da det innebar stora investeringar vid inforandetav ny teknik i natet, enligt Per Lundh. Operatorerna ar motvilliga att investera i en teknik som de intedirekt kan ta betalt for.

Antalet som kan utnyttja tekniken, d.v.s. har en GPRS-telefon, ar inte tillrackligt stort for att operatorernaskall gora investeringen. Detta kan liknas vid ett dodlage, dar, slutanvandarna vantar med att kopa enGPRS-telefon som operatoren stoder i sitt nat tills slutanvandaren vet vilka (mervardes)tjanster somtekniken mojliggor. I andra andan vantar operatorerna med att i full skala tillampa GPRS-teknologin,da de inte har en klar bild av vilka tjanster som de vill erbjuda och stodja. Troligtvis kommer nog inteoperatorerna att sjalva leda utvecklingen av applikationer till SIM-kort. De blir endast leverantorer avdet fysiska mediumet och tekniken, vad som mobiltelefonen anvands till (e-handel, biljettbokning mm.)kommer tredjeparter att utveckla och salja.


42(62) DEL III: 4. Utredning av teknologier4.7 Framtiden



9 december 1999

Trots att GPRS inte ar ett bredbandsalternativ sa tror Per Lundh att det anda kan innebara ett hot motW-CDMA-tekniken och detta kan resultera i en trolig forsening av inforandet av W-CDMA.Ytterligare problem finns med GPRS ar hastigheten. Den grans som ar av intresse ar gransen for streamingvid videosandningar, 115 kb/s. Nasta generation GPRS, EDGE - Enhanced Data rate for GSM Evolution,skall klara 384 kb/s, vilket ar mer an det dubbla som GPRS idag klarar av. Men EDGE kommer inte attborja anvandas tills det att GPRS ar utbrett, da EDGE kommer blir en utokning av GPRS.

4.7.3 Marknaden styr

Det som troligen kommer att ske ar att vissa intressenter, pa marknaden och inom industrin, kommer framtill att den andra generationens mobiltelefoni ar ’forlorad’. De kommer da att driva pa utvecklingen avapplikationer anpassande for den tredje generationens mobiltelefoner. Denna handling genomfors for attskapa ett sug pa markanden - jamfor med hur Microsoft agerar, de levererar produkter som i det narmastetvingar kunderna att aven kopa in andra Microsoft-produkter, darfor de ar enklare att samkoordinera ochanvanda tillsammans, an t.ex. tillsammans med en tredjepartsprodukt.

4.7.4 Historien innehaller inte hela sanningen

Inom en (men for telekombranchen lang) snar framtid, fyra till fem ar, kommer det att finnas en uppsjoav luftburna och Internetbaserade mervardestjanster och tekniker (HSCSN - High Speed Circuit SwitchedNetwork, WAP, SAT, E-commerce). Det som da mobiloperatorerna maste beakta ar hur de skall investeraoch vilka resursavvagningar som de maste gora. En operator kan valja mellan ett 20-tal olika losningarvarav fyra gar att integrera med operatorens nat och teknik och dar endast tva ar praktiskt genomforbara.Hur skall operatoren valja?Det historien visar ar att under de senaste fem till sex aren sa har en likriktning skett for mobiltelefo-noperatorer. De tenderar alla att satsa pa samma teknik vilket innebar att viss teknik inte kommer attspridas och anvandas. Men Per Lundh anser inte att historien innehaller hela sanningen for de kommandesituationerna ”. . .det enda sakra man kan saga om framtiden ar att man inte vet sakert. . .”

4.7.5 IP - ar ett krav

Det kommer aven att ske ett paradigmskifte dar marknaden och industrin gar fran kretskopplade tillpaketformedlande tekniker. Detta kraver dock att vissa faktorer ar uppfyllda:

1. En bra paketformedlandetjanst maste finnas och anvandas, t.ex. GPRS

2. Det maste finnas full IP-support med IP-terminering (alla komponenter ar IP-adresserade). T.ex. sakommer det kanske vara mojligt att via FTP38 hamta och bearbeta filerna pa ett SIM-kort.

Paradigmskiftet haror ifran skiftet dar fixa nat gick ifran paketformedlande och kretskopplade teknikeretc. till ren IP. Vad som maste goras ar att knyta samman och specificera Internet- och GSM-standarder,vilket kommer att leda till mer oppna system(losningar).

Klientlosningar till telefon och kort kommer i storre utstrackning att utvecklas av tredjepartsleverantorer,t.ex. en browser for SIM-kort med olika applets (miniprogram med olika funktioner). Det mest begransandevid utvecklingen av applikationer for kort ar den mycket begransade bandbredden (kommunikationen medett SIM-kort ar valdigt langsam da operativsystemet pa kortet arbetar med en frekvens pa ca 1-5 MHz[18]).

4.7.6 Uppdelning av mobiltelefon

Telekomsystemleverantorer, sasom Ericsson och Nokia, som har mycket egenutvecklade och patentskyd-dade (proprietary) losningar kommer att utveckla mobiltelefonen i tva delar. Den ena delen kommer attinnehalla ljud och radiogranssnitt och den andra blir inriktad pa mervardestjanster. Skalet till detta aratt en andring i radio- eller kommunikationsgranssnittet innebar att telefonen maste typgodkannas. Ge-nom en uppdelning behover de inte fa hela telefonen typgodgand nar de infor tillaggsfunktionalitet imervardestjanstedelen.

38File Transfer Protocol





9 december 1999

4.7.7 WAP - Wireless Application Protocol

Operatorerna kommer att kunna erbjuda en WAP-losning pa SMS om kunderna vill ha det. Det somframtiden kommer med, ar en integration mellan WAP-teknologier och datorer, med s.k. plug-ins etc.Detta kommer att skapa ett sug och efterfragan pa produkter som stodjer WAP. Dock sa tror Per Lundhoch Across Wireless att det kommer att ske ett bakslag for WAP. Detta ar nagot som Across Wirelessforutsatter och beaktar i sin systemutveckling och affarsstrategi.

Faktorerna bakom detta bakslag ar att marknaden aven vill ha andra losningar, t.ex. sa kallade WAP-shortcuts (WAP-losning pa andra teknologier) och tillaggsfunktionalitet.

4.7.8 WIG

En alternativ losning till en ren WAP-teknologi ar det av Across utvecklade WIG-systemet (WirelessInternet Gateway). Detta system agerar som WAP, men har dessutom full sakerhet i bada andarna (mo-biltelefonen m.h.a kortets sakerhetsfunktioner samt vid Internetbrowser m.h.a SSL, Secure Socket Layer).I dagens lage finns det annu inga specifikationer for hur sakerheten implementeras i WAP.

Utover sakerhetsaspekterna har Across WIG-system ytterligare en fordel da slutanvandarna inte behoverha en WAP-telefon. Det enda som kravs ar att SIM-kort och mobiltelefonen stodjer SAT, vilket de flestatelefoner gor i dagslaget. En funktion, som WIG-systemet ar ensam om att stodja, ar att pa WML-niva(Wireless Markup Language) kunna ha sakra signeringar. Ett annat problematiskt omrade for WAP arhur dynamiska IP-adresser skall allokeras och detta finns idag inte specificerat.

4.7.9 Framtidens aktorer

Telekombranchen innefattar ett stort antal olika aktorer.

• leverantorer

– tillverkarekorttelefonisystemtelefonervaxlar

– tredjeparterutvecklaremjukvarahardvarasystemdatakom

• kunder

slutanvandare

operatorer

leverantorer

tredjeparter

Tabell 5: Intressenter och aktorer inom telekombranchen. Tabellen illustrerar att det ar manga inblan-dade med ibland olika positioner (leverantor, tillverkare, kund etc.) och att granserna intear helt uppenbara.

Per Lundh tror att de olika intressenterna kommer att bli mer beroende av varandra. Det kommer inte attbli en vinnare (jamfor med Microsoft pa PC-marknaden for operativsystem) utan det kommer att bli olikatyper av samspel och konsortium (joint venture) dar intressenterna tillsammans kommer att utveckla nyaprodukter och tjanster for att sedan dela pa vinsten.

Nar systemen och teknikerna blir mer oppna, vilket Per Lundh tror, kommer antalet aktorer att vaxa.De aktorer som har mest kunskap om systemens proprietary losningar kommer vaxa sig starka da dennakunskap ar en viktig faktor i utvecklingen av framtidens mobilsystem.





9 december 1999

Del IV

Genomforande

5 Metod

Malet och syftet med detta examensarbetet var (se avsnitt 1.3 for de ursprungliga formuleringarna.):

- ”Kartlagga bakomliggande faktorer for de overgripande systemkraven.”

- ”En rapport med aspekter for autotester och kravhantering.”

- ”Om det ar mojligt att automatisera vissa tester, da utveckla en prototyp som mojliggor dennaautotestning.”

For att na dessa ovanstaende mal valdes foljande angreppssatt:

1. att undersoka vilka delar som ar mest tidskravande i den nuvarande testproceduren (som beskrivs iavsnitt 5.1), och

2. darefter genomfora en kravstudie kring testproceduren (avsnitt 5.2.3), och tillsist

3. intervjua personer som har kunskap om de overgripande aspekterna (avsnitt 4.7).

5.1 Matningar pa dagens tester

For att fa en battre forstaelse av dagens testproblematik utforde jag den befintliga testproceduren sjalv.Testet jag genomforde amnade reda ut huruvida ett SIM-kort fran en mobiltelefonoperator stodde OTA-meddelanden. Testmiljon som sattes upp, figur 29, innehaller de grundlaggande systemdelarna som deflesta testerna vid AU-System Mobile anvander.

Figur 29: Testmiljon vid OTA-uppdateringar.

Det som skiljer testerna at ar oftast vilken eller vilka servrar som ar kopplade till Transportservern och idetta testfall var det OTA-servern. Samtidigt utforde Johan Andre ett likadant test och detta gjorde attvissa delar tog langre tid for mig, bl.a. omstarter av servrar mm. som kraschat. Da vi var riktiga nyborjarepa all utrustning etc. fick vi anda fram ett resultat enligt figur 30.Resultatet i figur 30 ger en inblick i hur tiden fordelas under testets gang (det som illustreras ar medelvardetav olika OTA-nedladdningar) som tog runt sju timmar att genomfora for Johan. Jag lyckades ej genomforahela testet, men det gjorde Johan och det ar medelvarden fran hans test som illustreras.


45(62) DEL IV: 5. Metod



9 december 1999

Figur 30: Fordelningen av tiden mellan GSM-natverksfordrojningar och det manuella arbetet.

Fordelningens resultat ar inte framtaget pa ett strikt statistiskt satt39, men det ger trots allt en grovuppskattning av vilken del som ar mest tidskravande (och aven mest enahanda).Ur detta resonemang kom vi fram till tva fragestallningar:

1. Skulle det vara kostnadseffektivt att automatisera det manuella arbetet?

2. Kan GSM-natet lyftas ut ur kedjan av systemkomponenter?

5.2 Skall testerna automatiseras?

Detta ar en svar fraga att besvara. Samtliga av forfattarna som skrivit om autotester, Caner, Tilo/Daigloch Marick[23, 26, 24, 25] papekar a det starkaste hur forsiktigt man skall ga tillvaga i valet att utvecklaautotester. Speciellt nar testerna involverar testobjekt med frekventa andringar i anvandargranssnitten.

Med detta i atanke kom vi fram till att det skulle kunna innebara en forbattring i testprocessen om manutnyttjade ett inspelningsverktyg som en robot. En robot som inte testar anvandargranssnitten genom attmata in data och lasa av resultatet utan istallet syftar till att styra applikationerna. Denna styrning liknarett vanligt autotest fran ett CR-verktyg som startar programmen, matar in olika kommandon och sedanverifierar resultatet o.s.v.

Denna metod forutsatter att klientapplikationernas fel inte paverkar testresultatet. Forvisso ar testfallenmanga till antalet och olika, men det ar ett andligt antal testfall som alla kan realiseras och darmedjamforas med ett CR-verktyg.

AU-System Mobiles autotestverktyg bestod av Rationals[27] Visual Test. Detta verktyg visade sig dock ef-ter en evaluering infora nya begransningar pa projektet[34]. Dar den storsta begransningen lag i svarighetenatt jamfora rena textfalt mellan applikationer. Detta implicerar att Visual Test aldrig kan mojliggora heltautomatiska tester. I de (kommande) testfallen for SAT-applikationerna finns det inte nagon grund for au-tomatisering da de inte anvander de olika verifieringsapplikationerna (SIMPOS, Toolbox som AU-Systemtagit fram)[6, 7].

Syftet med utvecklandet en testapplikation var inte relaterat till anvandargranssnitten pa de olika applika-tionerna i OTA-SC och verifieringsapplikationerna (se avsnitt 4.6.2) och deras upptradande i OTA-miljon.Det var att forst och framst mojliggora kommunikation med SIM-kortet utan GSM-natet och MS, enligtfigur 4 och darmed lagga grunden for effektivare tester av kortstoden. Denna applikation blir saledes, enligtMarick[26], den s.k. stodkoden som testerna amnar undersoka.

39Langt senare sade dock var handledare, Staffan Lindgren, att nar de raknar pa overforingstider for SMS brukar deanvanda ett varde runt 80 s.


46(62) DEL IV: 5. Metod5.2 Skall testerna automatiseras?



9 december 1999

Med denna utgangspunkt valde vi att anvanda inspelningsverktyget Visual Test i nagra av OTA-testfallenfor att utrona om det skulle vara lampligt att investera i ett mer kraftfullt CR-verktyg. De testfall som viskapar kommer trots allt aldrig att kunna bli helt automatiserade sa lange som Visual Test anvands. Deblir semiautomatiska, da testaren sjalv maste gora den visuella verifieringen av nedladdningsresultatet.

5.2.1 Ar en applikationsprototyp lamplig?

Det ar uppenbart av resultatet i figur 30, avsnitt 5.1, att en applikation som kan emulera GSM-natet ochmobiltelefonen skulle kunna eliminera de relaterade fordrojningarna. Vilken funktionalitet som applikatio-nen bor ha kan diskuteras, da det finns ett stort antal tillvagagangssatt att valja mellan. Grunden ar attapplikationen skall stodja kommunikation med Transportservern, men som t.ex.

1. aven simulerar en mobiltelefon med ett grafiskt interaktivt granssnitt, eller

2. aven simulerar SIM-kort, eller

3. bade simulerar kort och telefon.

Dessa tre forslag ovan avfardade vi da:

1′. Detta kan vara lampligt vid SIM Application Toolkit tester dar det sker mycket interaktion mellanett SIM-kort och en telefon. Dock sa skulle detta ta for lang tid att utveckla, betydligt mer an 20veckor, vilket ar ramen for detta examensarbetet.

2′. Intressant ide dar testprocessen skulle kunna bli betydligt snabbare. Stod for samtliga kort skullebehova implementeras vilket skulle bli ohanterbart, da det standigt kommer nya kort och tiden dettar att utveckla ett sadant system ar troligen inte forsvarbar (jamfor med 3.2.2 for autotester enligtCaner[24]).

3′. Konceptet ar aven det intressant, men faller utanfor ramarna pa samma satt som 1′. och 2′.

Sammantaget leder detta till att en enkel applikation som endast stoder kommunikation med transport-servern och ett SIM-kort och som placeras i systemkedjan enligt figur 31 skulle vara en lamplig losning.

Figur 31: Figuren illustrerar den overgripande arkitekturen vid anvandandet av den nya testprocedurenmed en applikation. Den lilla gubben motsvaras av en testare vid sin dator som kor allaapplikationer [B1].





9 december 1999

5.2.2 Tillvagagangssatt

Pa AU-System Mobile anvander man sig av ett flertal olika utvecklingsmetoder vid forstudier och kra-vinsamling, bl.a Rationals Use Cases, RUP - Rational Unified Process med Rational Rose40 och EricssonsPROPS. Dessa metoder gar under det gemensamma namnet AU-pROPs.Innan modellerings- och implementationsfasen valde vi att gora en snabb utredning av AU-System Mobilesutvecklingsmetoder. Det vi da kom fram till var att

1. tiden det skulle ta att ordentligt lara sig dessa metoder inte skulle racka till, d.v.s. att projektetstidsram skulle sprackas och darmed skulle projektet bli langre an 20 veckor.

2. en modellering m.h.a. AU-System Mobiles utvecklingsmetoder inte skulle kunna anvandas till fullo.Da vi hade tillgang till en stor del kod att ateranvanda ansag vi att metoderna inte skulle kunnautnyttjas for fullt, da modelleringsverktyget (Rose) ingar som en del i metoden. Vi var aven vid dentidpunkten ej helt insatta i vad vi skulle ateranvanda och hur detta skulle paverka en modelleringmed Rose.

3. det skulle bli merarbete med dokumentgenereringen i ett projekt med endast tva stycken personeraktivt involverade.

Vagen vi valde var att anvanda vart sunda fornuft och de grundlaggande projektstyrningsdelarna i JonasAnderssons Miniprojekthandbok[35] for dokumenthantering.

5.2.3 Krav

Kraven som den nya applikationen maste uppfylla togs fram genom fyra olika moten och diskussioner medolika kommande anvandare.

Personerna som involverades i kravspecifikationsfasen var; Staffan Lindgren, Testansvarig pa AU-SystemMobile och var handledare, Hilde Digernes, mycket sakkunnig inom SIM-kort och kortstod samt FredrikBroman, sakkunnig inom SIM Application Toolkit.

Utover dessa personerna fanns det aven den del tysta krav som ingen person direkt stallt. Dessa tystakrav har en karaktar som ligger i omradet mellan allmanna perspektiv, overgripande faktorer och tekniskagranser.

I kommande avsnitt finns kraven uppstallda och indelade tre huvudgrupper enligt kommunikations- ochtestkrav samt overgripande systemkrav. Formuleringarna ar samma som de som finns i kravspecifikation-en[B1], fran 1999-08-03 (vissa delar har fortydligats). For varje krav finns aven en notering, enligt tabell 6,som indikerar vem som har stallt kravet.

Kravets ursprung Beteckning

Allmant/Overgripande/Tekniska A

Fredrik Broman F

Hilde Digernes H

Johan & Thord J T

Staffan Lindgren S

Tabell 6: De narmast involverade personerna i kravprocessen.

40Rational Rose ar ett mjukvaruutvecklingsprogram som anvands for modelleringar.





9 december 1999

Kravformuleringarna ar utformade i tre nivaer; inledning med ett namn (rubrik), darefter foljer en merstringent beskrivning och till slut kommer eventuell bakgrund, motiv eller forklaring till kravet (i kursivstil).

Overgripande systemkrav1. HelhetenA,S,J ,T

Systemet som helhet med dess komponenter skall ej paverkas. Samtliga systemkomponenter skallkunna agera och operera pa samma satt som om applikationen inte var inkopplad. Detta ar viktigtda man vill behalla systemets normala upptradande vid testerna.

2. AutomatiseringA,S,J ,TTestforfarandet skall automatiseras. For att kunna automatisera testerna behovs en effektiv testplatt-form, som erhalls genom att nyttja ett testverktyg (Visual Test), applikationen och en kortlasare ochsatta upp det enligt figur 31 och sedan extrahera olika testscenarior.

3. TransportservernJTAlla SM som kommer fran Transportservern, TS, skall skrivas ned pa kortet. Eftersom SMS-C ochtelefonen ersatts av en applikation skall saledes allt som ar kommer fran TS formateras och skrivasned pa kortet.

4. TermineringSTester skall kunna terminera mot ett SIM-kort. For att kunna testa kortstod.

5. ExpanderbarSDet skall vara en expanderbar applikation. Applikationen skall implementeras pa sadant satt att

- det ar enkelt att lagga till nya funktioner

- det inte kravs nagra storre eller omfattande andringar av applikationen da narliggande system-komponenter genomgar mindre andringar.

6. TestfallJTDe testfall som skall tas om hand om ar endast de grundfall, fem stycken till dags datum. For attdet ska vara mojligt for Johan Andre och Thord Schibler att gora fardigt projektet inom tidsramarnafor examensarbetet avgransas antalet testfall.

7. ApplikationerJTDe applikationer som behover skall kunna fa ta emot bekraftelser (ackar). De klientapplikationer somvanligtvis far bekraftelser fran exempelvis ett SMS-C skall nar applikationen anvands fortfarande fadessa.

Kommunikationsspecifika krav

8. SFMASamtliga SMS-typer skall stodjas:

(a) 7-bitars

(b) 8-bitars

(c) Unicode (16-bitars)

Dessa ar de tre nuvarande standardiserade SMS-formaten och dessa maste darfor stodjas helt.

9. Protokoll for SMS-CAEndast ett protokoll i SMS-C bor anvandas och det skall vara CMG-UCP som anvander sig avTCP/IP. UCP, Universal Computer Protocol ifran CMG[29].

10. Terminal ResponseA,FVid SAT-meddelande skall det alltid, vid behov, skickas ett terminal-response till kortet.





9 december 1999

11. SEND-SMFAlla send-sm som en SAT-applikation genererar skall skickas vidare till Transportservern.

12. SAPFAU-Systems internt utvecklade kommunikationsverktyg, SAP (SIM Application Platform, bestar avett flertal C++-API) bor anvandas for att forenkla kodingen och slippa explicit programmerings-tradning.

Testspecifika krav

13. VerifieringSDet skall vara mojligt att verifiera resultatet av en skrivning. Efter en skrivning vill man kunnakontrollera vad som blev nedladdat och aven hur det gick.

14. LoggarJT ,FAlla operationer, transaktioner och bekraftelser (ackar) skall loggas i fil. En typisk rad i loggen borinnehalla:

(a) datum

(b) tid

(c) debugniva

(d) status

(e) vilket kommando som utfort vad.

15. TestverktygSVisual Test bor anvandas for att kunna verifiera resultatet av en skrivning. Visual Test bor anvandasfor att den har mojligheter att styra Toolboxen. Pa sa satt kan nya tester laggas till med ett skriptsom da relativt enkelt kan verifieras.

16. TP-OAHDet skall vara mojligt att konfigurera tp-oa, Transfer Protocol Originating Address, i en initierings-fil41 som lases av applikationen.

5.2.4 Begransningar

De begransningarna som innefattas i denna del, utover tidsbegransningen, var att endast ett SMS-C-protokoll, se avsnitt 5.2.3 krav 9, skall anvandas darutover skulle hansyn tas till de eventuella begransningarsom anvandandet av Visual Test medfor. Vid anvandandet av Visual Test allokeras datorn42 som en resursoch det gar inte att kora andra program under tiden testverktyget exekverar.Vidare fanns det en del tysta krav, t.ex. att ateranvanda kod vilket leder till att hela testprocessen borutforas vid testutforarens egna dator, da delar av koden ar skapade for Windows NT-arbetsstationer(kortgranssnittet, DLL).

5.2.5 Arkitektur

Arkitekturen for den nya testmiljon, figur 31, grundar sig i att de gamla testerna utfordes vid en NT-station dar testaren hade tillgang till applikationerna och en mobiltelefon. Detta ansag vi vara viktigt;att kunna utfora tester vid sin normala arbetsplats och ha mojligheten att kunna gora nagonting annat(skriva rapport, eller lasa e-post) nar fordrojningarna i GSM-natet gjorde sig paminda.Dock forsvinner fordrojningarna i GSM-natet vid anvandandet av applikationen vilket innebar att kortlasarenskulle kunna kopplas in vid en godtycklig arbetsstation. Men som namns i foregaende avsnitt 5.2.4 fannsdet en del tysta krav som implicerar att testerna bor utforas vid testarens egna dator, t.ex. att det ar

41En ini-fil ar en fil som innehaller globala data, flaggor, varden och miljovariabler liknande med liknande syntax ochsemantik som Windows initieringsfiler, exempelvis, win.ini.

42d.v.s. den dator som Visual Test exekveras pa





9 december 1999

enklare om kortlasaren finns vid testarens arbetsplats och dator. Darfor blev kortlasaren placerad vid justtestaren och dennes arbetsplats (dator).Med denna konfiguration behover testpersonalen inte byta plats pa kort mellan kortlasare och mobiltelefonoch darmed ansags det att applikationen skulle vara placerad lokalt pa testarens dator. Pa sa satt forenklastestarbetet.





9 december 1999

6 Implementation

6.1 Utgangslaget

Innan en implementeringen genomfors bor man undersoka vad som redan finns och vad som kan ater-anvandas. Att aterandvanda kod, hard- och mjukvara kan innebara stora besparingar i tid och resurser.

6.1.1 Spraket

Da AU-System egenutvecklade mjukvaruplattform, SAP43 ar utvecklad i C++, samt att de dynamiskalankbibliotek (DLL, Dynamic Link Library) som vi skulle komma att anvanda aven de var utvecklade iC++, blev valet av sprak en enkel uppgift. Samtidigt ar utvecklingsmiljon for C++ pa Windows NT myc-ket behaglig da det ar valdigt enkelt att felsoka kod (avlusa/’debugga’ ) och utvecklingen underlattas av ettflertal hjalpfunktioner. Utover detta hade vi tillgang till Transportserverns kallkod, speciellt implemente-ringen av SMS-C-protokollen, som ar utvecklat i SAP. Saledes fanns det nu ett sprak, en utvecklingsmiljooch manga rader kallkod att forkovra sig i.

SIM-kortslasareEftersom AU-System Mobile utvecklar applikationer som ’Power GSM 44 och liknande produkter (se underavsnitt 4.6.2) fanns det redan stod implementerat for SIM-kortslasare. Det implementerade stodet bestodi dynamiska lankbibliotek, DLLer. En DLL ar en uppsattning funktioner i ett granssnitt mellan hardvaraoch mjukvara vilket mojliggor kommunikation mellan hard- och mjukvaran.

Dock sa fanns det ingen DLL som uppfyllde alla krav for oss. Men vi valde den senast utvecklade DLLensom anvandes till ett nyutvecklat program (den kommande Toolbox 2.0[6]). Den saknande vissa nod-vandiga funktioner, envelope, fetch & terminal response och det var tyvarr inte mojligt att lataflera applikationer kommunicera med SIM-kortgranssnittet. Denna funktionalitet behovdes for att kunnaverifiera innehallet i en fil pa SIM-kortet.

SMS-C-ProtokollSom tabell 4 visade finns det sex protokoll som alla stods av AU-System. Av dessa sex stods tva stycken ien en testapplikation till Transportservern. Testapplikationen fungerar som en inverterad Transportserver,d.v.s. alla inkommande SM tas om hand genom att skicka rapporter och bekraftelser (’ackar’) tillbakatill Transportservern. Denna funktionalitet som genererade rapporter och bekraftelser sag vi som mycketnodvandig da aven stod for UCP-protokollet fanns implementerat i den inverterade Transportservern.

OS-plattformAlla PC som AU-System anvander har Windows NT som operativsystem och darfor blev detta det natur-liga valet av os-plattform.

6.2 Design

De designbeslut vi tog var att:

1. anvanda oss av en inkrementell modell45 vid implementeringen

2. ateranvanda sa mycket kallkod som mojligt

3. dela in implementationen i tre faser enligt figur 32:43SAP, SIM Application Platform. Denna plattform ar inte utformad for SIM-kort, utan ar ett grundlaggande ramverk for

de flesta av AU-Systems olika servrar och klienter. Meningen ar att kallkod skall kunna utvecklas oberoende av operativsystem,Windows eller Solaris. Namnet ar lite missvisande men det ar ett gammalt arbetsnamn som hangt kvar[9].

44Power GSM ar ett verktyg som ger en anvandare mojligheter att administrera sin telefonbok pa SIM-kortet genom enkortlasare kopplad till en PC.

45(design, implementation, test, verifiering, design, implementering, . . .)


52(62) DEL IV: 6. Implementation



9 december 1999

Figur 32: Arkitekturen med implementationsfaserna [B2].

(a) Kommunikationsgranssnitt mellan TS och applikationen.Implementeras i moduler som tar hand om in- och utgaende meddelanden samt utfor de nodvandigadatakonverteringar. Initierar nedladdningar till kortet.

(b) Kortgranssnittet med DLL och kortlasare.De, for narvarande, tva olika nedladdningstyperna, OTA och SAT, implementeras utifran enmeddelandetypshuvudklass. Utfor skrivningar pa SIM-kort Dar funktionaliteten for OTA imple-menteras forst.

(c) Testmiljoer.Skript och de automattestforfaranden kodas och tas fram.

4. borja med att parallellt genomfora fas a) och b)

5. inte implementera extra finesser, utan endast fokusera pa minimumfunktionaliteten

6. ha kontinuerliga uppfoljningsmoten dar designen och arbetet diskuterades samt losningar och pro-blem belystes

ArkitekturenVid tre olika modelleringsmoten togs den interna arkitekturen fram dar vi fokuserade pa en modularfunktionalitet. Detta for att forenkla underhall, vidareutveckling och felsokning. Vilket skulle visa sig varatill extremt mycket hjalp, se avsnitt 6.2.4. Arkitekturen, beskriven i bilaga [B2] avsnitt 2.4, visas aven ifigur 33, dar GS indikerar de olika grasnsnitten.

6.2.1 Kommunikation

Kommunikationsgranssnittet mot applikationen bestar av tva delar; dels emuleringen av ett SMS-C ochdels emuleringen av en mobiltelefon. Dessa delar maste vara val utformade for att inte paverka funktiona-liteten i systemet, enligt helhetskravet i 5.2.3. Transportservern skall fungera som om den ar uppkoppladmot ett SMS-C och SIM-kortet skall agera som om det satt i en paslagen mobiltelefon uppkopplad motGSM-natet.


53(62) DEL IV: 6. Implementation6.2 Design



9 december 1999

Figur 33: Programarkitekturen for applikationen [B2]

Extern kommunikationApplikationens beteende mot Transportservern och kortet skall folja foljande steg:

1. Transportservern skickar ett meddelande, SM, till applikationen.

2. Applikationen bekraftar mottagandet med en ack och darefter gors skrivning till SIM-kortet av detmottagna meddelandet.

3. Beroende pa resultatet, ’ok’ eller ’nok’, av nedladdningen genereras lamplig rapport som sands tillTransportservern.

4. Transportservern bekraftar rapporten med en ack.

Figur 34: Flodet mellan Transportservern, applikationen och SIM-kortet.

Intern kommunikationDa vi tagit fasta pa att ateranvanda sa mycket kallkod som mojligt (SMS-C-protokoll och kortgranssnitt)och samtidigt utnyttja flexibiliteten av multitradning[31] i applikationen, ledde detta till vissa ovantadeproblem.





9 december 1999

• Forst blev det mer kallkod som vi ateranvande fran den inverterade och vanliga Transportservern,som var utvecklade under Solaris-C++46 vilket innebar vissa oforutsedda felsokningar och konver-teringar.

• Vid anvandandet av tradning i programmeringen maste olika handelser och forlopp undvikas (dodlage,race conditions etc.) som latt uppkommer da olika tradar vantar pa samma resurs eller pa varandra.Sedan finns det aspekter kring prestanda som loses genom att lata tradarna vara sa oberoende avvarandra, d.v.s. de skall kunna utfora sa mycket nyttigt arbete som mojligt sjalva.

• I och med de ovanstaende punkterna blev det sma forandringar i arkitekturen som beskrevs i figur 33.Den resulterande interna arkitekturen illustreras i figur 35.

Figur 35: De interna flodesdesignen hos applikationen. De delar med dubbelram exekverar som en trad[34].

IP-kanalhanterarenIP-granssnittet mot operativsystemet administreras via en IP-kanalhanterare. Den lyssnar efter inkom-mande trafik och overfor utgaende meddelanden. Vid ett inkommande meddelande skickas detta vidaretill Arbetaren.

ArbetarenArbetaren bearbetar inkommande och utgaende data. Vid inkommande data formateras detta data till ettinternt request som sedermera formateras till ett komplett nedladdningsbart SM. Formateringen sker viaSMS-C-protokollet. Darefter laggs requestet i Inkommandekon for vidare fard till Statushanteraren. Vidutgaende data ar forfarandet det motsatta och datat (requestet) hamtas ifran Utgaendekon.

46Visserligen bygger de pa SAP-ramverket, men det ar trots detta skillnader i den interna representationen av variablermellan C++ i NT och Solaris.





9 december 1999

KoernaKoerna anvands for att koppla samman olika moduler. Detta ar darfor det introducerar fordelar vidanvandandet av tradning, med den storsta fordelen ar att modulerna ej beror pa varandra vid sin exekve-ring.

StatushanterarenStatushanteraren avgor vad som skall goras med meddelandet. Den hamtar data fran Inkommandekonoch undersoker typen pa meddelandet. Om det ar ett SM sa skickas det vidare till Meddelandehanterarenfor vidare nedladdning pa kortet. En inkommande ack, en bekraftelse ifran Transportservern pa en tidi-gare skickad rapport, termineras, enligt del fyra i figur 34. Vid en nedladdning vantar Statushanterarenpa resultatet ifran Meddelandehanteraren och genererar darefter en lamplig statusrapport som laggs iUtgaendekon.

MeddelandehanterarenMeddelandehanteraren arbetar mot SIM-kortgranssnittet enligt den sessionstyp som ar satt i initieringsfilen(se avsnitt 6.2.3). Tva olika sessioner ar implementerade; OTA och SAT. Alla statusmeddelande ifran SIM-kortet skrivs till en specifik logfil, for att forenkla analysen av SIM-kortets beteende.

Skalet till att Meddelandehanteraren ar tradad ar for att mojliggora framtida versioner av applikationenatt kunna anvanda fler an en kortlasare. Detta gor det mojligt att testa fler kort samtidigt, se underavsnitt 7.3, Fortsatt arbete.

6.2.2 Loggning

I SAP finns det en mycket valstrukturerad loggningsmetod. Detta forenklade arbetet vad det gallerinforandet av flodes och handelseloggar och analysen av vad som hander vid fel etc. ar mycket val un-derstodd.

6.2.3 Anvandarkonfigurationer

For att ge applikationen flexibilitet vad galler konfigurationsmojligheter utnyttjar applikationen en ini-fil. I denna fil kan anvandaren satta vissa parametrar beroende pa vad som amnas goras. Det framstaar att stalla in vilken typ av nedladdning som ar aktuell. Vid OTA-nedladdningar behovs ytterligareinstallningar goras. En av de viktigaste installningarna ar utfardarens adress (Originating Address, OA)som vid OTA-nedladdningar maste vara korrekt sa att OTA-nyckeln fungerar, se avsnitt 4.4.3. Sedan liggeraven PIN-koden i ini-filen da den oftast ar olika, aven for testkort, och alltid maste finnas tillhands forvissa funktioner pa SIM-kortet.





9 december 1999

6.2.4 Iaktagelser under utvecklingen

Under utvecklingen och framforallt under implementering uppkom ett flertal problem. Nastan samtligakan relateras till resursbrist pa AU-System, dar:

1. det forst och framst var problem med granssnittet mot kortlasaren. Att ge flera applikationer samtidigtillgang till SIM-kortgranssnittet gick inte att genomfora. Detta beror pa att verifieringsapplikatio-nerna[6, 7] inte ar utvecklade med en och samma DLL. Detta medfor att en verifieringsapplikationvid uppstart tar kortlasaren som en resurs och slapper den inte forran applikationen avslutas. Dettalostes genom att lata den nya applikationen sjalv slappa kortlasarresursen47 nar den inte anvands.Pa sa satt kan de andra applikationerna[6, 7] komma at kortet for att verifiera kortets innehall.

2. funktionaliteten for SIM Application Toolkit, SAT, ej kunde testas, darfor inget lampligt SAT-SIM-kort funnits tillgangligt.

3. ett krav inte gick att verifiera; krav 8, SFM, under avsnitt 5.2.3, sid 49. Stodet av Unicode-SM harinte verifierats darfor det inte finns nagra lampliga verktyg for detta inom AU-System. I dagslaget ardetta inte ett sa stort problem da det sallan utfors tester med Unicode, dock sa bor det implementerasi framtiden for att kunna verka pa den asiatiska marknaden.

4. avrundningen av testningen och verifieringen av den nya applikationen avslutades med upptacktenav fel i det dynamiska lankbiblioteket (DLL) som applikationen anvande. Dessa fel faller utanforprojektets ram, men de som utvecklat biblioteket kommer att ratta till de felen.

5. den ateranvanda kallkoden fran Transportservern innehaller aven den felaktigheter. Aven dessa fel-aktigheter faller utanfor projektets ramar, men, da de andringar som vi infort ar valkommenteradeoch resterande koddelar ar opaverkade, blir det inga storre problem att felsoka och ratta vid envidareutveckling av applikationen.

6.2.5 Verifiering

For att verifiera funktionaliteten och beteendet hos applikationen som vi tog fram har en hel del testergenomforts. De olika testerna som utfordes var i grunden samma som de manuella, beskrivna i avsnitt 1.2.2,men med anvandandet av den nya applikationen. Testerna amnade verifiera att alla giltiga inkommandeSM formaterades ratt och att SIM-kortet samtidigt upptradde pa ett korrekt satt och detta lyckades vigenomfora och verifiera. Vissa delar (Unicode och SAT) har dock inte testats pa grund av de orsakerbeskrivna i det forra avsnittet 6.2.4.

47Kortlasaren slapps genom att lata Meddelandehanterarens trad terminera.





9 december 1999

7 Resultat

For att kunna analysera hur den utvecklade prototypen inverkar pa testproceduren genomfordes sammamatningar som i avsnitt 5.1. Detta resultatet visas i figur 36, i foljande avsnitt.

7.1 Autotestets prestanda

Resultatet i figur 36 visar att beslutet att infora en applikation lonar sig. Fordrojningarna minskade med96%, vilket innebar att det endast tar 3s/SM med applikationen istallet for 83s/SM.

Figur 36: Fordelningen av tiden i de tre fallen.

Automatiseringen blev dock inte sa framgangsfull. Vinsten av att spela in testforfarandet paverkade intetiden for testproceduren over huvudtaget. Vi valde att inte rakna med tiden det tog att spela in testet48,da vi inte ar expertanvandare av Visual Test. Skalet till att automatiseringen inte gjorde testet mertidseffektivt ar att den storsta delen av det manuella arbetet, vid anvandningen av applikationen, bestodi att vanta pa att verifieringsapplikationerna skulle starta och avslutas.

Med detta resultat anser jag att det inte lonar sig att automatisera testerna om det endast ar tidsfaktornsom ar av intresse att minimera. Men med en automatisering slipper trots allt testaren gora det enahandatestarbetet manuellt och endast gora den visuella verifieringen (vilket ar en positiv effekt, speciellt nastagang ett test skall genomforas).

7.2 Slutsatser

En av de grundlaggande malsattningarna for detta projekt var att undersoka om dagens och de kommandetestprocedurerna kunde bli effektivare och i sadant fall utveckla denna effektivisering. Undersokningen led-de till identifieringen av tva tidskonsumerande delar i den befintliga testproceduren, det manuella arbetetsamt fordrojningar i GSM-natet. I diskussionen for att minska dessa partier uppkom tva fragestallningar:skulle en automatisering av det manuella arbetet i testproceduren reducera tiden? och skulle en bypass avGSM-natet kunna reducera dess fordrojningar?

Fragestallningen kring automatiseringen blev inte latt att besvara. Da AU-System inte har nagra lampligatestverktyg formulerades fragan om for att undersoka om det skulle lona sig att investera i ett kraftfullaretestverktyg, genom att gora testerna semiautomatiska. Slutsatsen av denna undersokning blir att detskulle bli en dalig investering. Detta grundar sig pa att tiden som automatiseringen tar att utveckla,underhalla och kora testet inte star i proportion till det vanliga manuella testarbetet. Vidare finns detflera olika tester som amnar testa och verifiera olika delar av proceduren vilket gor det svart att designaett fullskaligt autotest.

Anvandandet och inforandet av en applikation som emulerar GSM-natet och mobiltelefonen anser jag varaen mycket lyckad losning. Den far ned fordrojningarna med 96% och hela testproceduren effektiviseradesmed 65%, vilket jag anser vara ett lyckat resultat och en avsevard vinst. Implementationen av applikationen

48forberedelsen och inspelningen av ett test med Visual Test tar betydligt mer an ett par minuter.


58(62) DEL IV: 7. Resultat



9 december 1999

utfordes med minimumfunktionalitet och for att fa ut maximal nytta vid anvandandet bor funktionalitetenutokas, vilket designen enkelt medgor.

7.2.1 De bakomliggande faktorerna

Det jag sett som den mest viktiga faktorn kring detta projekt ar hur testningen vid AU-System utfors.Foretaget ar inne i en fas dar de utvecklar mycket mjukvara som sa fort som mojligt skall installeras hoskunderna. Detta leder till att vissa delar i utvecklingen forbises, speciellt tiden for att utfora ordentligatester och felsokningar. Testpersonalen far inte tillrackligt med tid for att utfora alla nodvandiga tester.

Inforandet av den nyutvecklade applikationen i testprocessen tror jag kommer leda till en mycket hogreeffektivitet hos vissa testprocedurer. Trots att automatiseringen inte forbattrade tidsaspekterna ar minuppfattning att det manuella arbetet blivit betydligt mindre.

En annan intressant del av arbetet ar studien i kravhantering. Det skrivs mycket om kravhantering i teorin,men som Macaulay[21] skriver i sin teoretiska bok, finns det alldeles for lite praktiska beskrivningar.

Vid genomforandet av utvecklingen och implementationen markte jag att det inte lonat sig att folja enval beskriven teoretisk metod, eller for den delen, anvanda nagon av AU-Systems metoder for mjukva-ruutvecklings, se avsnitt 5.2.2. Det hade inte lonat sig tidsmassigt, da det sannolikt hade introduceratforseningar.Projektet var inte menat till att gora en helt nyutvecklad applikation. Enkelt uttryckt handlade det sna-rare om att med all befintlig funktionalitet, som fanns kring de olika systemdelarna (Transportservern,kortlasare och DLL), satta ihop en ny applikation. Hade vi gjort en nyutveckling hade det nog varit betyd-ligt battre att anvanda sig av de olika modelleringsverktygen som AU-System Mobile har och anvander.Men da vi valde att atervanda sa pass mycket funktionalitet (kod) som mojligt, for att pa sa satt kunnaklara av projektet inom 20 veckor, blev arbetet mer av lara sig det befintliga delarna (Transportservern,kortlasare, DLL och SAP) for att sedan implementera applikationen via minsta motstandets vag. For attgora detta behovdes ingen valstrukturerad teoretisk utvecklingsmodell.

7.2.2 De overgripande aspekterna

En intressant aspekt kring vilken typ av informationsbarare som anvands ar den att de system medSMS som informationsbarare49 inte kommer att kunna leverera prestandatjanster. Detta grundar sig i detfaktum att de flesta operatorers SMS-C i dagens lage inte har namnvart hog prestanda. Detta tror jag i sintur beror pa att dagens SMS-trafik inte ar av speciellt stor vikt. Kunderna kraver inte att trafiken skall varaav ett visst matt, de nojer sig med det som finns. SMS-meddelanden om att det finns nya meddelandeni rostbrevladan behover inte levereras direkt. Min uppfattning ar att dagens anvandare anser att ettmeddelande fran rostbrevladan kan komma inom 30 till 60 minuter - annars borde val mobilanvandarnapapekat detta for operatorerna? Jag vet att jag nojer mig med det. Trots att jag tycker att ett SMS franmin rostbrevlada bor komma inom 15 sekunder nar min telefon slas pa eller far natkontakt, sa nojer jagmig med att det ibland tar upp till en timme. Istallet valjer jag att inte lita pa eller anvanda mig av SMSda det ar bradskande.

Ett vanligt SMS-C klarar idag av en trafik pa ca tio in- och utgaende SM per sekund, vilket maste ansesvara mycket lagt. Av detta foljer att endast applikationer som inte kraver speciellt snabb leverans kananvandas. Jag tror inte att man vill vanta en halvtimme for att fa betala eller bestalla en biobiljett enfredagseftermiddag via mobiltelefonen, det kanns orimligt.

Enligt Per Lundh, se avsnitt 4.7, kan prestandakraven kring vilken informationsbarare som anvandskringgas. Losningen ar att anvanda det sa kallade MAP-protokollet SS7 i en MSC-gateway dar ett SMS-Cinte anvands50. I framtiden kommer aven GPRS att anvandas som informationsbarare, och som GPRS-teknologin ar utformad kommer meddelandepaketen dels att skickas med hogre hastighet och sandas viafler kanaler an vad som sker vid en SMS-overforing idag.

49T.ex. Across Wireless Internet Gateway-system anvander sig av SMS som informationsbarare.50MAP - Mobile Application Part, SS7 - Signalling System 7 ar ett plattformsoberoende signaleringsprotokoll. Anvands

vid utveckling av mjukvaruverktyg som skall forenkla designen av tradlosa (wireless) och intelligenta natverk, IN.


59(62) DEL IV: 7. Resultat7.2 Slutsatser



9 december 1999

7.3 Fortsatt arbete

Testproceduren vid AU-System Mobile kan utokas pa ett flertal olika satt vid anvandandet av applikatio-nen. En av de mest patagliga fordelarna ar mojligheten att infora flera kortlasare till applikationen, sa atttester kan utforas parallellt pa flera kort, vilket skulle kunna utgora en betydande forbattring.

Mojligheten att testa SAT-applikationer ar en del som maste implementeras. Projektet hade ursprungligenplanerna att genomfora detta men det gick ej att genomfora pa grund av brist pa tid, resurser och stodfran de sakkunniga.

Kring anvandandet av den nyutvecklade applikationen finns det ytterligare en intressant aspekt, da denanvander sig av SMS-C-protokoll for att kommunicera med Transportservern. For att undersoka hur dessaprotokollimplementeringar uppfor sig kan dessa laggas till i applikationen som da mojliggor testning avprotokollens beteende.


60(62) DEL IV: 7. Resultat7.3 Fortsatt arbete



9 december 1999

Referenser

[1] AU-Systems officiella hemsida http://www.ausys.se

[2] Across Wireless officiella hemsida http://www.acrosswireless.com

[3] ”Product specification AviSIM OTA Service Centre 3.1”, AU-System Mobile, 1999

[4] ”Product specification - Wireless Service Management”, Anders Floden, 1999, AU-System Mobile

[5] ”Product specification - Wireless Internet Gateway”, Anders Sellin, 1999, AU-System Mobile

[6] ”Product specification - AviSIM Toolbox 1.0”, AU-System Mobile

[7] ”Product specification - AviSIMPos”, AU-System Mobile

[8] ”Product specification - Transport Server”, Anders Mansson, 1999, AU-System Mobile

[9] ”AviSIM Sap Utilities Api Interface Description”, 1999, AU-System Mobile

[10] ”AviSIM OTA Client-Server Protocol”, Hilde Digernes, 1999, AU-System Mobile

[11] ”SIM: an Overview”, Mack Palomaki, 1997, AU-System

[12] ”Om GSM”, http://home.swipnet.se/OsbyMikro/omgsm.htm, 1999

[13] ETSI, GSM 02.07, version 4.8.2, ”Digital cellular telecommunications system (Phase 2); Mobile Stations(MS) features”, 1998-01

[14] ETSI, GSM 02.11, ”Digital cellular telecommunications system (Phase 2); Service accessibility”, 1996-09

[15] ETSI, GSM 02.24, ”Digital cellular telecommunications system (Phase 2); Description of Charge AdviceInformation (CAI)”, 1996-01

[16] ETSI, GSM 03.38, ”European digital cellular telecommunications system (Phase 2); Alphabets andlanguage-specific information”, 1994-09

[17] ETSI, GSM 03.40, version 6.1.0, ”Digital cellular telecommunications system (Phase 2+); Technicalrealization of the Short Message Service (SMS); Point-to-Point (PP)”, 1998-07

[18] ETSI, GSM 11.11, version 7.0.0, ”Digital cellular telecommunications system (Phase 2+); Specificationof the Subscriber Identity Module – Mobile Equipment (SIM — ME ) interface”, 1998-07

[19] ETSI, GSM 11.12, version 4.3.1, ”Digital cellular telecommunications system (Phase 2); Specification ofthe 3 Volt Subscriber Identity Module - Mobile Equipment (SIM-ME) interface”, 1998-03

[20] ETSI, GSM 11.14, version 7.0.0, ”Digital cellular telecommunications system (Phase 2+); Specificationof the SIM Application Toolkit for the Subscriber Identity Module — Mobile Equipment (SIM — ME )interface”, 1998-07

[21] ”Requirements Engineering”, Linda A. Macaulay, 1996, ISBN 3 - 540 - 76006 - 7

[22] ”Challenges in Requirements Engineering”, Janis A. Bubenko, 1995,http://www.dsv.su.se/ janis/RE95.html

[23] ”Classic Testing Misstakes”, Brian Marick, 1997, http://www.rstcorp.com/classic/mistakes.html

[24] ”Improving the Maintainability of Automated Test Suites”, Cem Kaner, 1997,http://www.kaner.com/lawst1.htm

[25] ”How to Automate Testing of Graphical User Interfaces”, Tilo Linz, Matthias Daigl, 1998,http://www.imbus.de/html/GUI/AQUIS-full paper1.3.html


61(62) REFERENSER



9 december 1999

[26] ”When Should a Test Be Automated?”, Brian Brian Marick, 1998,http://www.rstcorp.com/papers/abstracts/automate.html

[27] Visual Test, Rational, ”http://www.rational.com/products/visual test/index.jthtml”, 1999-07-05

[28] ”Evaluation of CASE tools by a Test Specifications Model (TSM)”, Tero Ahtee, 1997,http://www.cs.tut.fi/ tensu/Eval-CASE.html

[29] Officiell hemsida for CMG http://www.cmg.com, 1999-10-03

[30] Officiell hemsida for IEEE, http://www.ieee.org

[31] ”Multithreading for Rookies”, Ruediger R. Asche, Microsoft Developer Network Technology Group,September 24, 1993, http://msdn.microsoft.com/library/techart/msdn threads.htm

[32] ”Hemuppgift i Telekommunikationssystem; Assignment 2”, Fredrik Alriksson, 1999-04-18

[33] Examensarbete; ”Software Testing in Distributed Object Oriented Systems”, Erik Bohman, december1997

[34] Examensarbete; ”Automated test procedure for GSM Over-The-Air SIM file management”, Johan Andre,1999-11

[35] Jonas Andersson, ”Industriella Styrsystems Miniprojekthandbok for elevprojekt och examensarbeten”,1997, ISBN 91 - 7170 - 195 - 8

Bilagor

[B1] Thord Schibler, Johan Andre, Nulagesanalys & Kravspecifikation, ”JTXM01.doc”, 1999-08-17

[B2] Thord Schibler, Johan Andre, Systemspecifikation, ”JTXM02.doc”, 1999-08-16


62(62) BILAGOR

Nulagesanalys & Kravspecifikation

Thord Schibler/Johan AndreExamensarbetare vid AU-System Mobile 1999

17 augusti 1999

Bilaga B1


Nulagesanalys �→ Kravspecifikation

99-08-17

Innehall

Ordlista & Forkortningar 1

1 Bakgrund 21.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Avgransningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Testning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 SIM-kortstester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Automatisering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.1 Autmatiserad testmiljo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Krav 42.1 Overgripande systemkrav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 HelhetenA,S,J ,T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 AutomatiseringA,S,J ,T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 TransportservernJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 TermineringS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.5 ExpanderbarS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.6 TestfallJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.7 ApplikationerJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Kommunikationsspecifika krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 SFMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Protokoll for SMS-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.3 Terminal ResponseA,F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.4 SEND-SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.5 SAPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Testspecifika krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.1 VerifieringS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 LoggarJT ,F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.3 TestverktygS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.4 TP-OAH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Referenser 6

Thord Schibler, Johan AndreExamensarbetare, 1999

Dokument: JTXM01.doc

Bilaga B1



99-08-17

Ordlista & Forkortningar

AviSIM KlientapplikationerAdministrator & Service Assistant somhanterar nedladdningar och uppdate-ringar till SIM-kort

GSM Global System MobileGSM 11.xx Specifikationer som innehaller kom-

munikationsprotokoll for kommunika-tion mellan ME och SIM-kort och STKoverforingar

ME Mobile EquipmentMobil enhet/Telefonen

Komponent SystemkomponentDe systemdelar som mojliggor upp-datering och hantering av SIM-kortoch dess data, enligt figur 1.

OTA Over-The-AirSamlingsnamn for de funktioner somkan andra datat pa ett SIM-kort ge-nom att skicka SMS

SAP SIM Application PlatformInternt kommunikationsverktyg somforenklar kodning av bl a tradning

SEND-SM Meddelandetyp som genereras av SIM-kortet

SFM SIM FileManagementKlientapplikation

SIM Subscriber Identity ModuleSMS Short Message Service

SMS-C Short Message Service CentreServer

SMS-Gateway Skoter kopplingen mellan TS och SMS-C

STK SIM ToolKitFunktioner som stodjer nedladding avapplikationer, menyer mm. pa en MEoch SIM-kort

STM SIM Toolkit MessagingSimpos AviSIMPOS

Mjukvara som via en kortlasare kanarrangera datat pa ett SIM-kort ge-nom diverse olika funktioner

System Alla delar och komponenter som finnsmellan ett SIM-kort och en klientap-plikation, se figur 1

TP-OA Transfer Protocol Originating Add-ressDen adress som utfardar ett SMS, och

som da skall ta emot ett eventuelltsvar

TS TransportserverBestar av tre delar SFM, SMS-Gate-way och OTA-Server

Toolbox Mjukvara som via en kortlasare laseroch visar filer (filstrukturbaserat) paett SIM-kort och som kan uppdateraoch andra dessa

TR Terminal ResponseSvar somME kan skicka till SIM-kort-et som bekraftelse


Dokument: JTXM01.doc 1(6)

Bilaga B1



99-08-17

1 Bakgrund

1.1 Inledning

Vid testning av SIM-kort och stod for dessa ar man oftast tvungen att (skarpt) anvanda sig av GSM-natet. Speciellt da man vill testa ny funktionalitet sasom applikationer, nya funktioner eller allmannanedladdningar pa kortet. Da GSM-natet och dess inverkan pa overforingen inte tillfor nagot for testningenav SIM-kortet onskar man elimiera detta i kedjan, se figur 1, av systemkomponenter vid testforfarandet.

Figur 1: Kedjan av systemkomponenter.

1.2 Avgransningar

Malet ar att lyfta ut de komponenter som inte paverkar resultatet av SIM-kortsnedladdningar utan attpaverka nagon funktionalitet i systemet. Efter ett mote 990628, [1], beslutades det att allt mellan Trans-portservern (TS) och SIM-kortet, d.v.s. SMS-C, GSM-natet och telefonen (ME), inte skall vara med vidtestningarna och istallet skall en ny systemkomponent ta over och emulera kommunikationen mellan TSoch SIM-kort. Den grafiska representationen av ME och SIM-kortets innehall kommer inte att emuleras.

1.3 Testning

Testning kan delas in i tre olika grupper som markant skiljer sig fran varandra vad det galler badeforvantningar pa resultat och vilka skal som ligger bakom en testning.

• Tillfallig testningTester som utfors da och da (ad-hoc-karaktar) och som inte ar namnvart stora i omfang och tid.

• Parametrisk testningNar en produkt ar i slutfasen och det skall verifieras att den dels har den forvantade funktionalitetenoch ett dartill horande “korrekt” upptradande. Dessa tester ar, mer eller mindre, av iterativ karaktaroch de tar mycket tid och ar valdigt omfattande. De kan dock delas in i s.k. canned–transactions sombestar av i forvag noga programmerade standardmassiga1 scenarior.

• Sofistikerad testningTester som utfors av ingenjorer, forskare, utvecklare o.s.v. Dessa tester har en valdigt komplexkaraktar och ar stundom tidskravande.

1.4 SIM-kortstester

Pa AU-System finns de tre testprinciperna enligt 1.3 representerade och de foljer i stort sett forfarandetsom illustreras i figur 2. Klientapplikationer anvands for att mata in data och SMS som skall ned pa kortet.

1Med standardmassiga avses de for produkten vanliga scenarier, procedurer, forlopp m.m.



Bilaga B1



99-08-17

Figur 2: Testningsforlopp vid test av SIM-kort.

1. OverforingInformationen gar igenom TS som kommunicerar med DB och vidarebefodrar informationen vidaretill SMS-C. SMS-C lagger pa en header innan det skickas via GSM-natet till ME.

2. NedladdningME tar emot och laddar ned datat (filer, applikationer o.s.v.) pa kortet enligt GSM 11.11.

3. VerifieringDetta gar till pa olika satt beroende pa vilken typ av nedladdning det ar, exempelvis OTA, SMSeller STK.

(a) Via telefonens menyer direkt verifiera resultatet.

(b) Genom att lata SIMPos lasa pa kortet via en kortlasare och visa vad som finns pa kortet.

(c) Genom att lata SIM Toolbox lasa in filstrukturen fran kortet via en kortlasare och visa filer ochdess innehall.

1.5 Automatisering

Nar man valjer att automatisera ett test maste man gora en avvagning infor hur man tror framtidenkommer att paverka testet. Det ar oftast mindre kostsamt att en gang gora ett manuellt test an att tafram en automatisk testmetod for ett test. Pa samma vis ar det mindre kostsamt att utveckla en automatisktestmetod dar manga testomgangar skall genomforas jamfort mot att gora det manuellt varje omgang.For att fa en effektiv automatiserad testning av SIM-kortsnedladdningar ska vi utveckla denna nya system-komponent, namd under 1.2. Det blir en applikation med arbetsnamnet SIM-ShortCut som kommer attutfora dessa emuleringar. Darefter kommer ett testverktyg styra klientapplikationerna for nedladdningaroch verifieringar. Pa sa satt kommer det bli mojligt att utveckla effektiva testmiljoer for olika kortstod.

1.5.1 Autmatiserad testmiljo

Det som foljer efter anvandandet av ett testverktyg och SIM-ShortCut ar att skapa sig en bank av olikatester. Till en borjan bor man utveckla generiska tester for de kort som man vill stodja och sedan med dessasom grund ta fram specifika tester som subgrupper for de respektive korten. En faktor som gor att det blir



Bilaga B1



99-08-17

mindre kostsamt ar att alltid spara de tester-miljoer som gors for respektive kort for att pa satt bygga uppsin bank av fardiga tester. Sedan bor det ocksa finnas val dokumenterade besrkivningar av vad testernagor och forvantas resultera i. Det sistnamnda innefattas dock inte inom ramarna for examensarbetet.

2 Krav

De krav som vi, JA och TS, har tagit fram harur framst ifran de moten som varit, [1, 2].I kommande avsnitt, 2.2- 2.3, finns kraven uppstallda och indelade tre huvudgrupper enligt kommunikations-och testkrav samt overgripande systemkrav. For varje krav finns en notering som indikerar vem som harstallt kravet enligt:Allmant/Overgripande AFredrik Broman FHilde Digernes HJohan & Thord J TStaffan Lindgren S

2.1 Overgripande systemkrav

2.1.1 HelhetenA,S,J ,T

Systemet som helhet med dess komponenter skall ej paverkas. Samtliga systemkomponenter skall kunnafungera och operera pa samma satt som om SIM-ShortCut inte var inkopplad. Detta ar viktigt da man villbehalla systemets normala upptradande vid testerna.

2.1.2 AutomatiseringA,S,J ,T

Testforfarandet skall automatiseras. For att kunna automatisera testerna behovs en effektiv testplattformsom fas genom att nyttja ett testverktyg (Visual Test), SIM-ShortCut och en kortlasare och satta upp detenligt figur 3 och sedan ta fram olika testscenarior.

2.1.3 TransportservernJT

Allt som kommer fran TS, Transportservern, skall laddas ned pa kortet. Eftersom SMS-C och telefonenersatts av SIM-ShortCut skall saledes allt som ar kommer fran TS transformeras, formateras och laddasned pa kortet.

2.1.4 TermineringS

Tester skall kunna terminera mot ett SIM-kort.

2.1.5 ExpanderbarS

Det skall vara en expanderbar applikation. SIM-ShortCut skall implementeras pa sadant satt att

- det ar enkelt att lagga till nya funktioner

- det inte kravs nagra storre eller omfattande andringar av SIM-ShortCut da narliggande systemkom-ponenter genomgar mindre andringar.

2.1.6 TestfallJT

De testfall som skall tas om hand om ar endast de grundfall 4-5 stycken till dags datum. For att det ska varamojligt for JA och TS att gora fardigt SIM-ShortCut inom tidsramarana for examensarbetet avgransasantalet testfall.



Bilaga B1



99-08-17

Figur 3: SIM-ShortCut insatt i systemkedjan.

2.1.7 ApplikationerJT

De applikationer som behover skall kunna fa ta emot bekraftelser (ackar). Enligt 2.1.1-1 skall de klientappli-kationer som vanligtvis far bekraftelser (acknowledgement) fran exempelvis SMS-C aven da SIM-ShortCut

anvands fortfarande fa dessa

2.2 Kommunikationsspecifika krav

2.2.1 SFMA

Samtliga SMS-typer skall stodjas:

1. 7-bitars

2. 8-bitars

3. Unicode (16-bitars)

Dessa ar de tre nuvarande standardiserade SMS-formaten och dessa maste darfor stodjas helt.

2.2.2 Protokoll for SMS-CA

Endast ett protokoll i SMS-C bor anvandas och det skall vara UCP som anvander sig av TCP/IP. UCPstodjer tva kanaler sa att det blir kommunikation med full duplex mot SIM-kortet.

2.2.3 Terminal ResponseA,F

Vid STK-meddelande skall det alltid skickas ett terminal-response till kortet.

2.2.4 SEND-SMF

Alla send-sm skall skickas vidare till Transportservern.

2.2.5 SAPF

Det internt utvecklade kommunikationsverktyget SAP bor anvandas for att forenkla kodingen och slippaprogrammeringstradning.



Bilaga B1



99-08-17

2.3 Testspecifika krav

2.3.1 VerifieringS

Det skall ga att verifiera resultatet av en nedladdning. Efter en nedladding vill man kunna kontrollera vadsom blev nedladdat och aven hur det gick.

2.3.2 LoggarJT ,F

Alla operationer, transaktioner och bekraftelser (ackar) skall loggas i fil. En typisk rad i loggen kan in-nehalla:

1. datum

2. tid

3. debugniva

4. status

5. vilket kommando som utfort vad.

2.3.3 TestverktygS

Visual Test bor anvandas for att kunna verifiera resutatet av en nedladdning. Visual Test bor anvandasfor att den har mojligheter att kommunicera med och styra Toolboxen. Pa sa satt kan nya tester laggas tillmed ett script som da relativt enkelt kan verifieras.

2.3.4 TP-OAH

Det skall vara mojligt att konfigurera tp-oa, Transfer Protocol Originating Address, i en ini-fil2 som lasesav SIM-ShortCut .

Referenser

[1] //FRMNTW/DOCS/Kravdiskussion990628 v2.doc, sammanstallning av motesanteckningar fran990628.

[2] //FRMNTW/DOCS/Krav990706.doc, sammanstallning av anteckningar fran JA och TS “modelle-ring”.

2En fil med liknande syntax och semantik som Windows initieringsfiler (.ini) har.



Bilaga B1

Systemspecifikation

Thord Schibler/Johan AndreExamensarbetare vid AU-System Mobile 1999

16 augusti

Bilaga B2


Overgripande Systemspecifikation

99-08-16

Innehall

1 Introduktion 1

2 Design av mjukvaruarkitektur 12.1 Faser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1.1 Indelning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Detaljerad systemspecifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Moduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5 Felhantering/Loggning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.6 Fil/dataformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Krav 53.1 Overgripande systemlosningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 HelhetenA,S,J ,T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 AutomatiseringA,S,J ,T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.3 TransportservernJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.4 TermineringS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.5 ExpanderbarS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.6 TestfallJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.7 ApplikationerJT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Kommunikationsspecifika systemlosningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.1 SFMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.2 Protokoll for SMS-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.3 Terminal ResponseA,F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.4 SEND-SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.5 SAPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Testspecifika systemlosningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.1 VerifieringS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.2 LoggarJT ,F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.3 TestverktygS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3.4 TP-OAH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Referenser 8


Dokument: JTXM02.doc

Bilaga B2



99-08-16

1 Introduktion

Denna Systemspecifikation amnar beskriva hur kraven i kravspecifikationen ska uppfyllas. Den ar en be-skrivning av systemets struktur och hur de olika systemkomponenterna skall samverka. Samtidigt ar deten vagledning i det efterkommande konstruktionsarbetet (implementeringen) baserat pa de olika systemin-delningar, enligt:

• moduler

• granssnitt

• felhantering

• fil- och dataformat

• eventuella gemensamma datastrukturer

Alla krav i Kravspecifikationen kan saledes harledas till nagot delmoment i den presenterade losningen,i sektion 2 finns mer eller mindre implicita kravreferenser for den som ar valinsatt i kraven och i 3 arsamtliga krav uppstallda med respektive losningsatgard.

2 Design av mjukvaruarkitektur

Efter en omskriven, reviderad och till viss del utforligare Kravspecifikation, [3], valde JA och TS attfredagen den 6 augusti 1999 genomfora ytterligare en modellering, dar vi sag over hur vi skulle uppfyllakraven och hur dessa skulle implementeras. JA hade redan borjat titta pa AU-Systems ramverk och skrivitlite kod for testa hur det fungerar och agerar.

2.1 Faser

Implementeingen delas in i tre stycken delfaser:

a) Kommunikationsgranssnitt mellan TS och SIM-ShortCut .Implementeras i moduler som tar hand om in och utgaende meddelanden samt utfor de nodvandigadatakonverteringar. Initierar nedladdningar till kortet.

b) Kortgranssnittet med DLL och kortlasare.De, for narvarande, tva olika nedladdningstyperna, OTA och STK, implementeras utifran en med-delandetypshuvudklass. Utfor nedladdningar pa SIM-kort

c) Testmiljoer.Script och automatiska testforfaranden kodas och tas fram.

I fas c) kommer aven loggingen att implementeras.

2.1.1 Indelning

Fas a) och b) utfors parallellt av JA och TS och satts samman via de veckomoten beskrivna under 2.2.Detta for att arbetet skall flyta pa och samtidigt ge inblick i framskridandet och de eventuella problemsom (alltid) uppstar.Utover dessa faser kommer utvecklingen att indelas i:

1. TS tar hand om granssnitt mot TS, UCP, med initiering och uppstart av SIM-ShortCut .

2. JA borjar med granssnittet mot kortlasare, SIM-kort och DLL, dar OTA-tjansterna utvecklas forst,da STK-delen ar betydligt harigare och kraver ett standarformat over filerna pa SIM-kortet.

3. Efter lyckade tester av Fas a) och b) paborjas fas c).



Bilaga B2



99-08-16

Figur 1: Implementeringsfaser.

2.2 Detaljerad systemspecifikation

Under implementeringen kommer det att tas fram en mer detaljerad beskrivning av de olika systemdelarna.De olika delarna som vi anser behover detta kommer att beskrivas utforligt och all relaterad informationoch data1 kommer att redovisas. Dokumentet ar tankt som ett komplement till den valkommenteradekoden och det kommer att vaxa fram under de veckovisbaserade moten som JA och TS kommer att hallafor att hela tiden arbeta i samma riktning och klargora de metoder som implementeras. Det blir ej hellerett milstolpedokument.

2.3 Granssnitt

—?—

2.4 Moduler

Efter [4] fastslogs en indelning dar det finns 9 stycken moduler, se figur 2 vilken visar modulerna ar franoversta vanstra hornet till hoger och darefter nedat cykliskt:

1. IPIP-Kanalen som ligger mellan SIM-ShortCut och Transportservern. Denna kanal svarar for all kom-munikation mellan TS och SIM-ShortCut och stodjer dubbelriktad trafik.

2. SERVERInitierar lyssning pa port 4711 som TS, via IP, ar uppkopplad mot. Nar sedan ett meddelandekommer fran TS sker tre saker

(a) ett MSG-objekt initieras

(b) meddelandet sands vidare till UP

(c) en bekraftelse skickas tillbaka till TS, med det format som definierats i GSM 11.11.

I de fall dar det ar STK-meddelanden och ett send-sm genererats pa SIM-kortet, skickas dessa tillSERVER direkt fran MSG.

SERVERn initierar aven UP och Buffer via en Supervisor som hanterar alla objekt och trafikenemellan dem och kommer att arbeta i de tillstand som illustreras i 3.

1Exempelvis datastrukturer, format, klasstrad och algoritmer, mm.



Bilaga B2



99-08-16

Figur 2: Programarkitekturen for SIM-ShortCut

Figur 3: Tillstandsdiagram vid initiering av SIM-ShortCut fram till MSG.



Bilaga B2



99-08-16

3. UCPSvarar for det protokoll som anvander sig av TCP/IP. UCP Universal Computer Protocol.

4. UP (utlases UnPack)Alla meddelanden som kommer in fran TS omformateras och packas sa att de ar pa samma formsom de ar innan TS far dem, d.v.s. de ar pa det format som GSM 11.11 specifierar.

5. BufferMellanlagringsutrymme mellan UP (SERVER) och MSG, dar UP fungerar som Producer och MSGar Consumer. Bufferten innehaller endast ett meddelande at gangen och UP och MSG laser i denm.h.a. en binar semafor.

6. MSGHamtar meddelande fran Buffer och kontrollerar vilken typ av nedladdning det ar, STK eller OTA.Darefter skapas lampligt objekt som tar hand om skrivningen till kortet.

Figur 4: Meddelandetyper som objekt i UML.

Types ar innehaller alla gemensamma delar som STK och OTA har. Ett Types-objekt kommer dockaldrig att initieras utan det ar bara STK och OTA som skall initieras.

7. STKFormaterar och laddar ned meddelandet pa kortet. Ser aven till att eventuella send-sm skickas uppattillbaka till MSG.

8. OTAFormaterar och laddar ned meddelandet pa kortet.

9. DLLDynamisk lankfil som hanterar kommunikationen med SIM-kortet. Skall patchas med envelope ochfetch och mojligheten att flera applikationer kan lasa fran en och samma kortlasare.

2.5 Felhantering/Loggning

For att fa en enhetlig bild av fel- och handelsehantering med AUs ovriga mjukvaror kommer det service-paket for loggning som finns i SAP att implementeras pa sadant satt att SIM-ShortCut upptrader somvilket valprogrammerat AU-program som helst.

2.6 Fil/dataformat

Det filformat som ar av intresse for SIM-ShortCut ar Windows inifiler. Nedan visas syntaxen ar for dessafiltyper.

[Host]Address="172.16.6.20"



Bilaga B2



99-08-16

;172.16.252.32Port="4711"

Det som star inom hakparenteser kallas for nyckel och det som foljer darefter ar datavarden associerademed symobliska variabler. Ett semikolon (;) kommenterar bort efterkommande textrad.

Dataformatet som SIM-ShortCut kommer att arbeta med ar samma som TS, m.a.o. det standardiserade(bytekod) format som GSM 11.11.

DF1;DF2;DF3;EF1;CommandHeader1;Data1;EF2;CommandHeader2;Data2;EF3;CommandHeader3;Data3 o.s.v.

Nedanstaende rad lagger AU-Systems telefonnummer i position 1 i ADN-listan7F10;;;6F3A;A0DC01041C;41552D53797374656DFFFFFFFFFF06916478625700FFFFFFFFFFFFFF;

3 Krav

De tidigare avsnitten under sektion 2 har implicit beskrivit vissa systemlosningar utan att direkt hanforastill nagra krav. Nedan foljer de krav som finns upptagna i [3] med en beskrivning hur de kommer att losasoch uppfyllas.

3.1 Overgripande systemlosningar

3.1.1 HelhetenA,S,J ,T

Systemet som helhet med dess komponenter skall ej paverkas.

Losning Genom att lata all trafik som gar mellan TS och ett SMS-C istallet ga mellan SIM-ShortCutoch TS och samtidigt skicka de ackar som SMS-C normalt skickar till TS samt emulera en ME mot kortetkommer systemets funktionalitet ej att paverkas och upptradandet blir notmalt.

3.1.2 AutomatiseringA,S,J ,T

Testforfarandet skall automatiseras.

Losning Iochmed inforandet av SIM-ShortCut samt de, i fas c), framtagna testscenarior for Visual Testkommer automatiska tester att vara mojliga.

3.1.3 TransportservernJT

Allt som kommer fran TS, Transportservern, skall laddas ned pa kortet.

Losning Garanteras via de bekraftelser (ackar) som genereras och skickas tillbaka.

3.1.4 TermineringS

Tester skall kunna terminera mot ett SIM-kort.

Losning Mojliggors och uppfylls via inforandet och anvandadet av SIM-ShortCut .

3.1.5 ExpanderbarS

Det skall vara en expanderbar applikation.

Losning Vid programmeringen anvands god programmeringssed, -teknik och koddokumentation samten modulariserad uppbyggnad av funktionaliteten.



Bilaga B2



99-08-16

3.1.6 TestfallJT

De testfall som skall tas om hand om ar endast 4-5 grundfall.

Losning I fas c) kommer dessa att implementeras och utvecklas.

3.1.7 ApplikationerJT

De applikationer som behover skall kunna fa ta emot bekraftelser (ackar).

Losning Enligt 3.1.1 och 3.1.3 ar detta uppfyllt.

3.2 Kommunikationsspecifika systemlosningar

3.2.1 SFMA

Samtliga SMS-typer skall stodjas (7/8/unicode)

Losning Mojliggors via implementeringen av Types{STK, OTA}

3.2.2 Protokoll for SMS-CA

Endast ett protokoll i SMS-C bor anvandas det skall vara UCP som anvander sig av TCP/IP.

Losning Genom att ateranvanda kallkod fran Transportserver och den inverterade Transportservern.

3.2.3 Terminal ResponseA,F

Vid STK-meddelande skall det alltid skickas ett terminal-response till kortet.

Losning Implementeras i fas b).

3.2.4 SEND-SMF

Alla send-sm skall skickas vidare till Transportservern.

Losning Implementeras i fas a) och fas b).

3.2.5 SAPF

Det internt utvecklade kommunikationsverktyget SAP bor anvandas for att forenkla kodingen och slippaprogrammeringstradning.

Losning Ramverket och dess paket inkluderas och anvands flitigt vid kodningen.

3.3 Testspecifika systemlosningar

3.3.1 VerifieringS

Det skall ga att verifiera resultatet av en nedladdning.

Losning Vid en nedladding later man en appklikation oppna kortet och pa sa satt gar det att se vadsom blev nedladdat och hur det gick.

3.3.2 LoggarJT ,F

Alla operationer, transaktioner och bekraftelser (ackar) skall loggas i fil.



Bilaga B2



99-08-16

Losning Implementeras via ramverkets loggpaket i fas c).

3.3.3 TestverktygS

Visual Test bor anvandas for att kunna verifiera resutatet av en nedladdning.

Losning Uppfylls och implementeras i fas c).

3.3.4 TP-OAH

Det skall vara mojligt att konfigurera tp-oa, Transfer Protocol Originating Address, i en ini-fil.

Losning Implementeras via ett filhanteringspaket fran ramverkets i fas a). Ovriga normala installningarkommer aven att kunna konfigueras i inifilen.



Bilaga B2



99-08-16

Referenser

[1] //FRMNTW/DOCS/Kravdiskussion990628 v2.doc, sammanstallning av motesanteckningar fran990628.

[2] //FRMNTW/DOCS/Krav990706.doc, sammanstallning av anteckningar fran JA och TS “modelle-ring”.

[3] //FRMNTW/DOCS/JTXM01.doc-990817.pdf, Systemkravspecifikation med nulagesanalys. Milstol-pedokument fran Modelleringsfasen.

[4] //FRMNTW/DOCS/SIM Shortcut Arkitektur990806.doc, sammanstallning av anteckningar fran JAoch TS “designmodellering”, dar systemarkitekturen togs fram.



Bilaga B2

Styrandefaktoreroch ¨overgripandesystemkravvid testningavSIM...

Documents

Transcript of Styrandefaktoreroch ¨overgripandesystemkravvid testningavSIM...