African Automotive Industry Alliance
(AAIA)
AUTOMOTIVE INDUSTRYSTANDARD
IntelligentTransportation Systems (ITS)
Requirements forthe Automotive Industry Public Transport
VehicleOperation
INTRODUCTION
The African Automotive Industry Development Alliance (AAIA) felt the need for a programto implement the publicationofstandardsanddevelopmentoftestfacilitiesinparallelwhenthework onthepreparationofthestandardsisgoingon,asthedevelopmentofimproved safety criticalpartscanbeundertakenonly afterthepublicationofthestandardand commissioningoftestfacilities.Tothisend,theAfrican Automotive Industry Development Alliance (AAIA) hasconstitutedapermanentAutomotiveIndustry Standards Committee(AISC). The standards prepared by AISC will be approved by the permanent TechnicalStanding Committee.Afterapproval AAIA will publish this standard.
Intelligent TransportSystems(ITS) areglobally proven systemstooptimizethe utilizationofexisting transportinfrastructureandimprovetransportation systemsin termsof efficiency, quality, comfortandsafety.Havingrealizedthe potential ofITS, GovernmentbodiesandotherorganizationsinAfricaarepresently workingtowards implementingvariouscomponents ofITS across theregion.
The firststeptakenfor creationandimplementationof ITSwasholdinga Regional Workshoptitled“RequirementsforInteractiveITSArchitecture”,whichwas conductedasacollaborationbetween AAIA andStakeholders.Thiswasprimarilyfocused onITSinPublic BusTransportation.Nonetheless, the workshophelped tocreate theoutline for “IntelligentTransport System Architecture and PolicyforPublicTransport (Bus)”, which was submitted byAAIA to Africangovernments and transport ministries.
Inthe1st AAIC, the Chairmanhaddirected-standardizationactivitiesto be initiatedonIntelligentTransportationSystems(ITS)-VehicleLocationTracking, Camera Surveillance System and Emergency Request Button. The committee intendedtoextendtheaboveuser requirementstoallpublictransportationnamely– buses,taxis, etc.ThecurrentdocumentcoverstherequirementsforVehicleLocation Tracking andEmergencyButton.TheotherITScomponentslikePIS,CCTVsystem, Farecollectionetc.aredeliberatedandwouldbeaddressedinlaterphaseandcould beaddedas separate parts to the current document..
Basedonthese directions,the AAIA PanelonITShaspreparedthis document titled, “Intelligent Transportation Systems (ITS) - Requirements for Public Transport VehicleOperation”
Thepanelhasalsodeliberatedandidentifiedthenecessary elementsforaneffective implementation of vehiclelevelITS system.
Thisstandardhas beenpreparedby consideringinputsreceivedfromallstakeholders onITS, mainly-
a. Directions ofCMVR-TSC
b. DetailedSpecificationDocumentonVehicleTrackingDevices
c. ReportofDepartment ofTelecom(Telecom EngineeringCentre)Automotive
WorkingGroup on M2Menablement inIntelligent Transport System (ITS)
This AISonITS,hasbeenprovisionedfordevice levelapproval;including constructionandtargetvehicle levelapproval.Device levelapprovalisneededto enable retro-fitmentofITS systemsonin-use vehicles.ThiswillensureITSBackend Control Centre infrastructure alreadypresents with the STUs can be more fully utilizedandmake the investmentintheBackendControlCentreinfrastructure more viable.
Asper thedirectionofCMVR-TSCwhichneededthe CommunicationProtocoland Backend Control Centre requirement for tracking and handling the alerts to be detailed.
ThedeviceswouldtransmitdatatotheBackendControlCentreusing2G/3G/4G wirelessconnectivity (withSMSfallback)aspertheprotocol.
Thedata fromthedeviceswouldtraveloverthewirelesstelecomserviceprovider networkandfinally get deliveredattheBackendControlCentre.
BISand AISbothhavepanelswhichareformulating standardsonITS.Itisourbelief thattakingtheAISrouteforthe1st implementationwouldgivethefastertimefor adoption.ExpertsintheBISpanelandinDIMTSwhoareworking onthesesubjects have beenco-optedandinvitedtoworkintheAISpaneltomake the AISasrobustas possible. Once implemented and all implementation problems in this emerging
technology havebeeneliminated,BISstandardcanbemadewithfurtherinclusionsif any resulting fromconsultationswiththewider stakeholdercommunity.Because of these reasons,we recommendthe AISroutefor regulation creationandfirst implementation.
Oneofthemajorconcernswhichhasbeenraisedduring the panelmeetingsisonthe issueofprivacy encroachmentsbyITS systems.Someoverseasmembercountrieshavebeencontinuously emphasizinginWP29forumsthatthe regulatedITSsystem mustnotencroach on privacy.Towards this, the panelhas submittedadocumenttitled‘DataPrivacy inTransportationITS’Tohelpthesystem developersdealwiththese issues.Further,systemdeveloper canalsotake guidance from ‘IS/ISO/TR12859: 2009 -Intelligent Transport Systems— System Architecture
—Privacy AspectsinITSStandardsandSystems’whiledevelopingtheirsystemsto meettherequirementsof thisstandard.The PanelandtheAutomotiveIndustry StandardsCommittee (AISC)responsibleforpreparationofthisstandardaregiven.
Intelligent Transportation Systems (ITS)-Requirements for
Public Transport Vehicle Operation
1.0 SCOPE
1.A.0 Thisstandard applies toboth individual components as wellas system environmentintended tobeusedin Publictransport vehicles.
1.A.1INTELLIGENT TRANSPORTATION SYSTEMS-VLT WITH AN EMERGENCY SYSTEM
RequirementsonITSdevicesandfunctions- VehicleLocationTracking and EmergencyButton
2.0 APPLICATIONFORCMVRTYPE APPROVAL
2.1TheapplicationforCMVRdevicelevelapprovalshallbeaccompaniedby information on thesystem specification.
2.2 Typeapproval shall involve followingsteps:
2.2.1DeviceApproval:ApprovalprovidedatDevicelevelforcomplianceto this standard.
These approved devicescan befitted /retro-fitted bymanufacturer/ Dealer/ permitholder/systemintegratorinanyvehiclemodelprovideditshallmeet installationrequirements. FormanufacturersseekingvehiclelevelapprovalwithapprovedVLTwithEmergencyButtonsfittedshallonly requireinstallationapproval.
2.3 Modifications andExtensionofApproval
2.3.1 Every modificationpertainingtotheinformation,evenifthechangesare nottechnicalinnature declaredinaccordancewithclause 2.1,shallbe intimatedby theVLTwithEmergencyButtonManufacturer/tothetest agency.
2.3.1.1 Ifthechangesare inparametersnotrelatedtotheprovisions,nofurther action need betaken.
2.3.1.2Ifthechangesareinparametersrelatedtotheprovisions,thetestagency, whichhas issuedthecertificateof compliance,maythen consider,basedon thejustificationprovidedby theVLTwithEmergency ButtonManufacturer and reviewedbythetest agency, whether,
Themodelwiththechanged specifications still complies with provisions; Or,
Anyfurther verification isrequired toestablish compliance.
2.3.2Incaseof2.3.1.2,testsforonlythoseparameterswhichareaffectedbythe modificationsneedbecarriedoutbasedon Criteriaforextensionof type approval.
2.3.3Incaseoffulfilmentofcriterionofclause2.3.1.1orafterresultsoffurther verification asper clause2.3.1.2 aresatisfactory, the approval ofcompliance shall be extended for thechangescarried out.
3.0 ITSFUNCTIONS ANDREQUIREMENTS
ThelistofITSfunctionsenvisagedfromthisdevicetypeissetout.
Theabovefunctionsandtheirrequirementsshallbemetbyonlysingledevicethatcanbeinterfacedby externalemergencybuttons.The communicationstoBackendControl Server (Governmentauthorized server)shallbedoneby device.
3.1.1.1DeviceshallbecapableofobtainingpositioninformationusingGlobal Navigation Satellite System (GNSS). GNSSreceiverspecifications areas follows:
a. DeviceshallbecapableforoperatinginLand/orSbandandinclude supportfor NAVIC/IRNSS(AfricanRegionalNavigationSatellite System) fordevices installed on or after 1stApril,2018.
b. TheDeviceshallsupportGAGAN,theAfricanSBAS(SatelliteBasedAugmentation System)
c. Deviceshallhaveapositionaccuracy ofminimum2.5mCEPor6m
2DRMS
d. Deviceshall have anacquisition sensitivityof minimum(-) 148dBme. Deviceshall have an trackingsensitivityof minimum(-) 165dBm
f.Device shall have an internal antenna; however if in case of Integratedsystemswithvehicle/aftermarketOEMapprovedkitsif thefitmentlocationpreventstheinternalantenna fromfunctioning, then external antennashallbeprovided.
3.1.1.2 DeviceshallsupportstandardminimumI/Osasmentioned:4Digital,2
Analogueand1SerialCommunication(e.g.RS232)for interfacing external systems (E.g. Digital input for Emergency request button
interfacing).
3.1.1.3DeviceshallbecapableoftransmittingdatatoBackendControlServer (Government authorized server) via Wide Area (Mobile) Communicationsnetwork(GSM/GPRS) asper Communication Protocol.
3.1.1.4Device shall be capable of transmitting Position, Velocityand Time (PVTdata)alongwithheading (directionoftravel)toaBackendControl Server(Governmentauthorizedserver)atconfigurablefrequency.
The fixed frequencyshall be user configurable,minimum frequencyshall be5secduring vehicleoperationandnotlessthan10minutesin sleep/IGNOFF)asper the protocoldefinedinCommunicationProtocol ofSection 4.
3.1.1.5Deviceshallbecapableoftransmittingdatatominimum2differentIP addresses (1IP address forregulatorypurpose(PVTdata)and 1 IP addressforEmergency responsesystemotherthantheIP’srequiredfor Operational purpose.
3.1.1.6On pressing of Emergency button, the system implementing VLT functionshallsendemergency Alert(AlertID10asmentionedinSub- section 4.2.1 of Communication Protocol Section 4) tothe configuredIP address(s)asper the Communication Protocolmentionedin Section4.In theabsenceofGPRSnetwork,theemergency alertshallbesentasSMS messagealong withvehiclelocationdatatoconfiguredcontrolcenter number(s).
3.1.1.7Deviceshall have an internal back-up batteryto support 4 hoursof normaloperations(tobetestedfor positionalrecordtransmissionata frequencyof 60sec)
3.1.1.8DeviceshallbecapableoftransmittingalertstotheBackendControl Server(Governmentauthorizedserver) directly.
3.1.1.9 Deviceshall support over the air software and configuration update.
3.1.1.10Device shall support basic standard configuration (Mobile communicationsnetwork settings,BackendControl Server (Government authorizedserver)details,data frequencies, alert thresholdsetc.).
3.1.1.11Deviceshallsupportstoreandforwardmechanismforalltypeofdata (periodic dataandalerts) meantfor backendtransmission.The system shallstoredataininternalmemory duringcommunicationnetworkun- availability andtransmitthedatawhentheconnectionresumesinlastin firstout(LIFO)manner.Thelivedatashallbegivenhigherpriority for transmission than back log(stored data) at anypoint in time.
3.1.1.12TheDeviceshallhaveauniqueidentifierforidentifyingtheVLTdevice anddata.TheuniqueIDshallbestoredinareadonlymemoryareaso thatitcannotbealteredoroverwritten by anyperson.Theunique identifiermay beVehicleIdentificationnumberorIMEI(International Mobile Station EquipmentIdentity) Number.
3.1.1.13Deviceshallstore/writetheregistrationnumberofthevehicleinthe internal nonvolatile memory.
3.1.1.14 Deviceshall have an Embedded SIM.
3.1.1.15Deviceshallbedesignedtooperatebetween8VDCand32VDCusing vehiclebatteryinputvoltage range12/24Volts.
3.1.1.16 Deviceshallhaveasleepmodecurrent≤20mA(Ifthefunctionis
implemented in a dedicatedsystem/device).
3.1.1.17 DeviceshallsupportanyoperationalGNSSsystemwith12(minimum)
acquisitionchannels.
3.1.1.18 TheDeviceshall support:
• Location on GPRS/SMS
• Non-volatilememorytostoremin 40,000 positional log
• Configurable backup SMSfacilityin caseof GPRSfailure
• CapabilitytosendservingandadjacentcellIDaswellasnetwork measurement report (NMR)
3.1.1.19 TheDeviceGNSSmoduleshall have:
• The capabilityof Hot start 5s
• The capabilityof Warm start :30s
• The capabilityof Cold start < 40 s
3.1.1.20 Deviceshall support Outputs as per NMEA 0183
3.1.1.21 TheDeviceGPRSmoduleshall have:
• MultislotGPRSwith In-built Quad-band GPRSmodule/Modem
• GPRSclass 10 or above
• SupportEmbeddedSIMtocatertotheautomotiveoperational requirementsuchasvibration,temperatureandhumidity andprovide long life spanwithatleast10yearslife andmore than1million read/writecycles
• GPRSmodule &SIM shallsupport
oSMS, Data (GPRS, TCP/IP)and
oSupportmultiplenetworkOTAswitching(on-demand/automatic)
capabilities.
3.1.1.22Deviceshallbedust,temperature,vibration,watersplashresistant,IP65 rated orbetter, tamperproof as per Section 6.
3.1.1.23Deviceshallbemanufacturedusing processesas perqualitymanagement standardforautomotiveindustriesi.e.ISO/TS16949updatedfromtime to time
3.1.1.24 Deviceshall support A-GPS(Assisted GPS)
3.1.1.25DeviceshallhaveprovisionofsecureddatatransmissiontotheBackend ControlCentrefromthe devicesthrough secured channel(e.g. secured dedicated APN).
3.1.1.26Deviceshallhave3axisaccelerometerand3axisgyroscopeforgetting the alerts on harsh breakingharsh acceleration, and rash turning.
3.1.2 Functional Requirement forEmergency System
3.1.2.1Passengersorin-vehiclecrew presentinthevehicleshallbeabletomake an emergencyrequest bypressingthe emergencybutton provided
3.1.2.2The emergency request function shall not exist as standalone. The functionshallbepartofVehicleLocationTracking (VLT)system.An alertshallbesentto the BackendControlServer(Governmentauthorized server)whenemergency requestisraised.De-activationshallalwaysbe from authorized government server who receives alert message i.e.
3.1.2.3TheEmergencyButtonswillbe'NormallyClosed'(NC)type.Theform factorofEmergencyButtonswillbesuchthatthebuttonis easy topress inthecaseofanemergency,andsimultaneously alsominimizesthe possibilityof accidental or unintended press therebycausingafalse alert.
3.1.2.4On pressing of Emergency button, the system implementing VLT functionshallsendemergency Alert(AlertID10asmentionedinSub- section4.2.1of Communication Protocol Section4) tothe Backend Control Server (Government authorized server) as per the Communication Protocol mentioned in Section 4. In the absence of GPRS network, the alert shall be sent as SMS message along with vehicle locationdatatoconfiguredcontrolcenternumber.The SMSshall consist of parameters.
3.1.2.5In absence of both GPRS and GSM networks and on pressing of EmergencyButton,thesystemimplementingVLTfunctionshallstore theemergency Alert(AlertID10asmentionedinSub-section4.2.1of Communication Protocol Section 4). Once the GPRS or GSM is available,this alert information shall besent on high priorityto the configuredIPaddressesasperthecommunicationprotocolmentioned in Section4orasSMSmessagealong withvehiclelocationdatato configuredcontrolcenternumber.TheSMSshallconsistofparameters.
3.1.3 ConfigurationofDevice Parameters Over theAir (OTA)
The device shallsupportatleastthe belowparameterstobe configurable overtheair(throughSMSandGPRS).Theupdationshallbeallowed onlyoveran ‘authenticated’ channel:
1.Setting/ Changeof thePrimaryorSecondary IPand port number
2.Setting/Changeof theAPN
3.Setconfigurationparameterlikesleeptime,overspeedlimit,harsh braking,harshacceleration, rash turningthreshold limitsetc.
4.Emergencycontrol SMSCentreNumber(s)
5.Configuringthe vehicle registration number
6.Configuringthefrequencyofdatatransmissioninnormal/Ignition state/ OFFstatesleep mode/ Emergencystate, etc.
7.Configuringthe timeduration for Emergencystate
8.Capabilityto reset thedevice
9.Command to get theIMEIof thedevice
Configurable commandsmustinvolvethe followingfeatures:
SET: Forsettingthe parameters.
GET:Forenquiringregardingtheparameterssuchasmobilenumber, GSM strength, vehicle number and otherimportant parameters.
CLR: Forclearing certaincommands, alarms, alerts etc.
AftereachSET,GET,CLRcommandthedeviceshouldsendalertto
BackendControlCentre,asmentionedinSection 4Alert12,giving the details of Mode, mobile no/IPof control center sending commands.
3.1.4 TrackingDeviceHealthMonitoring Parameters
The device shallsendstatusof healthparametersatconfigurable interval andthisthresholdvalue shallalsobe configurableover the air.Itshallbe possiblefor healthparameterstobe fetchedondemandviacommand.
3.1.5 SMSFallBack
Incaseofemergency state,(i.e.onpressingofAlertbutton),thedevice willshiftto the SMSmodeincaseGPRSconnectivityisnotavailable.In suchcase,the devicewillsendtheAlertmessageandtracking data throughSMSmode.SinceSMShasthelimitationofsendingonly 160 characters,sothetracking datatobesentinone SMSwillhavefields- IMEI,Latitude, Direction,Longitude, Direction, location fix, speed, Cell ID,LAC(LocationAreaCode),DateandTimeasperemergency alert.
4.0 COMMUNICATION PROTOCOL
4.1 DataFrameFormat
Thelisting offieldsthatthevehicle tracking devices would be required to send to the Backend Control Centre.The first3fields(Startcharacter,Header for VLTwith EmergencyButtonsandVendorID,whohassuppliedthedevice)must befixedinpositionaswellasformat(Headerpartofframe).Restall otherfieldsarerequiredtobepresentinthelocationdatasentby the devicestothebackend,butcanbeinany sequenceorwithany separator betweenfields.The datavalue canbe either inAmerican Standard Code forInformationInterchange(ASCII)orinHEX format.Device must transmittheLoginmessage whenever itestablishes(re-establishesafter disconnection) its connectivity with Server with the specified fields. Login Messagewillcarryfollowinginformation:
• $DeviceName –Vehiclenumberon which the deviceis installed
• $IMEI–15 DigitIMEInumber
• $Firmware– Version of the firmwareusedin thehardware
• $Protocol-Version oftheframe format protocol.
• $LastValidLocation–Last location info saved at thedevice.
4.2 Messages &Alerts fromDevices
4.2.1Tablebelow(Table4B)containsthelistingofalertsthatneedtocome from the tracking devices. These alerts are applicable for both live packets as wellas the historypackets.
4.2.2 Incaseofemergencyalert,thealertmessageshallbesentto2different
IPaddresseshencethedeviceshallsupportminimum2IPaddresses(1
IPaddressforregulatory purpose(PVTdata)and1IPaddressfor Emergency responsesystemotherthantheIP’srequiredforOperational purpose.The PVTdatawillsendtheemergency alerttothesystem. Primary alertwillgototheemergency responseBackendControlCentre (NERS/MHA)asmaybenotified by theGovernmentofAfricainthe schema below:
Primary alertwillgototheemergency responseBackendControlCentre asnotifiedby theGovernmentofAfricaintheindicativeformatbelow (Table 4C):
*Aboveformatisindicativeonly.TheseFormatwillbenotifiedbythe
Government ofAfrica timeto time.
4.3 Testing ofConfigurationofDeviceParametersOver theAir(OTA)
The followingtestingwill be done for
1. Setting/ Changeof thePrimaryor Secondary IPand port number
2. Setting/ Changeof theAPN
3. Setconfiguration,parameterlikesleeptimeforspeed,harshbraking, rash turns, etc.
4. EmergencySMSCentreNumber
5. Configuringthe vehicle registration number
6. Configuringthefrequencyofdatatransmissioninnormal/Ignition state/ OFFstatesleep mode, Emergencystate, etc.
7. Configuringthe timeduration for Emergencystate
8. Capabilityto reset thedevice
9. Command to get theIMEIof thedevice
Configurable commandsmustinvolvethe followingfeatures:
SET: Forsettingthe parameters.
GET:Forenquiringregardingtheparameterssuchasmobilenumber, GSM strength, vehicle number and otherimportant parameters.
CLR: Forclearing certain commands, alarms, alerts etc.
5.0 CONSTRUCTION ANDINSTALLATION
(To beverified on component level and target vehicle level approval)
5.1 Requirements on vehicleinterfaceforVLTwithEmergency Button
Connector forPower
Therequirementsforinterfaceshallbeagreedbetween vehiclemanufacturer anddevicemanufacturer.
Standard connectorsconformingtoISO 15170shallbe used atvehicle side.
However, Device/System side connector/s shall be pre-agreed with equipment manufacturerby
VehicleOEM in thecaseof OE fitment ofthe systems
System supplierin caseof retro fitment in aftermarket.
These requirements do not apply to integrated systems with vehicle whereintegrationisdoneby vehiclemanufacturerand/orSystem Integrator.
5.2 Requirement ofEmergency System
Emergency buttonshallbeonetimepresstype.Separatereleaseaction fromauthorizedservershallbe requiredtobring backtheemergency buttonto normal modeor clearemergencyflag.
5.3 Physical Mounting
TheVLTsystemshallbemountedinasuitablelocationsuchawaythat itis not easilyaccessible/exposedto passengers.
Thisrequirementshallnotbeapplicableincaseofcombinedsystems
VLTwith HMI(HumanMachineInterface) displayin front ofdriver. Test agencyto verifythis onvehiclelevel approval.
Emergencybutton(s)shallbefittedinsuchawaythatevery passenger includingdriver shallbeable to access theEmergencybutton(s).
PassengerCarshallhave2emergency buttonsoneachpassengerrow easilyassessableby eachofthepassenger.Thereshallalsobeone dedicatedemergencybutton forthe driver.
PassengerTransportbusshallhaveemergency buttonsatlocationseasily visibleassessabletoallthepassengerssuchasevery 2metersonboth thesidesonpassengerseating area.Forseatsreservedforladiesthere shall beadedicated panicbutton for each row.
Test agencyto verifythis on vehiclelevel approval.
5.4 PowerSupply
Thevehicletracking devicewillbeinstalledonvehiclesinwhichthe powersupply voltagefromvehiclebattery iswidely varying(12V,24V etc.)andalsothepowersupply isnotasstableasthatincaseoffixed locations, especially during engine start-up and braking when the voltagecanfalltoaslowas9V.Typically electronicdevicesarevery sensitivetopowersurgesandspikes,andequipmentmay failiftheydo not receive stable power supply. The devices will need to have a resilientpowersupply unitthatcanwithstandsuchfluctuationsandthe devices also need to have power backup so that they continue to functionforsomedurationwhenthevehiclebatteryisnotfunctionalor is disconnected from thedevices.
Vehiclepower interfaceshall have
One commongroundlinked to vehicle chassis
One permanent power Supply (12/24V) connected to the vehicle battery
Onenon-permanentpowerline(12/24V)connecttothebatteryafter ignition
5.4.1 Electrical Wiring
Thewiring harnessusedinthedeviceshall betestedforflammability.
6.0FUNCTIONAL, PERFORMANCE, DURABILITY, ENVIRONMENTAL ANDPROTOCOLTESTS
6.1 VehicleLevelFunctional Tests
Followingfunctionalitiesforeachofthesystemsshallbedemonstrated at thevehicle, in casesystem is provided bythe vehicleOEM.
6.1.1 VehicleLocationTracking With Emergency Button
6.1.1.1Vehicle OEM shall only provide/ installed devices approved under component level testing.
6.1.1.2System transmits PVT information to Backend Control Center (2differentIPs)atuserconfigurablefrequency(minimum5seconds) via GSM/GPRS.
6.1.1.3Systemtocommunicatetocontrolcenterontheoccurrenceofthealerts capturedin Communication Protocol.
6.1.2 Emergency Request
Emergency requestfunction-Whentheemergency buttons(as applicable)placedanywhereinthevehicleispressedby any passenger/ crew,makesurethattheemergency requestmessageissend/receivedat the control center.
6.2 Component Level Functional Tests
Following functionalitiesforeachofthe systemsshallbedemonstrated. At the choiceof the manufacturer, these functionalitiescan alsobe alternately demonstratedatthevehiclelevelandshallbedeemedtobe complied with at component level as well.
6.2.1 VehicleLocationTracking
6.2.1.1 Standard connectorprovidedfor Power and other signals
6.2.1.2 Configuration ofdevice as per the standard format.
Local configuration upload shallbeverified
Configuration upload from control centershallbeverified
6.2.1.3 VehicleLocation data transmission to Backend ControlCenter.
6.2.1.4BackendControlCentreshallbeabletochecktheversionoffirmware loaded on the system.
6.2.1.5 Update the firmwareof thesystemfrom BackendControl Centre
6.3 DeviceLevelFunctional, PerformanceDurability Tests
The teststobe performedfor device levelapprovalsareaslistedbelow. These functionality check will be performed after each test as acceptance criteria –
Testedsystemsshallsatisfy generalfunctionalrequirementsatallthe specifiedranges duringthetest andafter thetest.
Followingto becheckedafter testing:
i) TrackingfunctionalityshallbecheckedviaBackendControlCentre for theVLTsystem
6.3.1 Functional Testing
FunctionalTestingshallbedone withthe acceptancecriteria aftercompletionofallthe PerformanceDurabilityTests.
6.3.3 DeviceLevel Environmental Tests
Theenvironmentalteststobeperformedfordevicelevelapprovals.
Followingto becheckedafter testing:
i)TrackingfunctionalityshallbecheckedviaBackendControlCentre forthe VLT with EmergencyButton.6.3.4
ii) Protocol Testing
Thisset oftesting needsto bedone for allcases namelyvehiclelevel testing andcomponent(Device) level testing.
Protocolisasetofrulestobefollowed bythedevicewhilesending data totheBackendControlCentre.The protocolcomprisesdataupdaterate, number offields,start character,endcharacter,alerttype etc. Protocol testinginvolvescheckingthecomplianceofdatasetsreceivedby the BackendControlCentreagainsttheprotocolbothwithrespecttothe datafieldsas welltheformat.Itisexpectedthatthedatacoming toa centralservershallbeexactly asrequiredundertheprotocol.Table below(Table6D)mentionsthevalidationprocessfor theprotocol communication.The followingtest would beperformed alongwiththe protocol testing ofthe device:a) Memory Storage
Thedeviceshall support40000 ormorepositional logs/packets. This isa functionaltestandthe device willbe simulated tobe innon– GPRScoverageareaandthelogswillbemaintained.Thecapacity ofloggingwillbe checked bymonitoringthelogson the device.
b) Messages &Alerts fromDevices
Tablebelow(Table6E)containsthelisting ofalertsthatneedto comefromthetrackingdevices.Thesealertsareapplicablefor both livepackets as wellas the historypackets.
7.0 DEVICE TO BACKENDCOMMUNICATION MECHANISM
The VLTdevice wouldtransmitdatatotheBackendControlCentre usingGPRSwirelessconnectivity (withSMSfallback)asperthe protocolprovidedinrespective sections(Sub-section6.3.4).The data from thedevices would travel over thewireless telecomserviceprovider networkandfinally getdeliveredattheBackendControlCentre.Since the permitholders/Device supplierswouldrequire tohave a valid communicationplan onSIMcards onthe devicesandwouldavail servicesfrommultiple telecomserviceproviders,the datawouldbe transmitted to the Backend Control Centre using the networks of multiple telecom serviceproviders.
Asuitablecontrolmechanismwouldbeestablishedforthedatatransfer fromVLTtoBackendControlCentre,asonlytheauthorizeddevicesshould be abletotransferdatatotheBackendControlCentreanda mechanismfor authenticating the devices/SIMs shallalso be put into place.
ThemechanismtosetuptheBackendControlCentreshallbedecidedby therespectivestates.Thestatescanchoseany ofthefollowingoptionsfor settingup theBackend Control Centre:
1. StatescansetuptheirowndedicatedBackendControlCentre,meeting theabovelistedmandatory provisionsandany otheroptionalfeaturesas theymaydecide
2. StatescanallowtelecomserviceproviderstoofferBackendControl Centre asa Value Added Service (VAS) tothe permitholders,meeting theabovelistedmandatory provisionsandany otheroptionalfeaturesas they may decide. In this case, the telecom service providers shall provideaccesstotheBackendControlCentretogovernmentofficials, as decided bytherespective state.
COMPOSITION OF AISC PANEL
Organizations; Integrated multi-modal transit systems, automotive research associations, transport institutes, vehicle research and development, automotive technology centers, petroleum institutes, farm machinery institutes, automotive associations, transport departments and directorates,SMEs, chambers of commerce, Leyland, Toyota, Nissan, Suzuki, Ford Motors, TVS Motor, Bajaj, Hero, Bureaus of standards, IT and Information communication companies, Heavy Truck manufacturers
African Automotive Industry Alliance (AAIA)
P.O.Box 29324 Kampala, Uganda
Tel: +256 753 632211 / +256 772 632211 / +256 704 762575
Email: ,