Statens vegvesen
Rammeavtale for kjøp av trafikkregistreringsutstyr for motorkjøretøy på faste stasjoner
Kunden ønsker tilbud på levering av rammeavtale for kjøp av trafikkregistreringsutstyr for motorkjøretøy på faste stasjoner.
Statens vegvesen er ansvarlig for å samle inn vegtrafikkdata (videre kalt trafikkdata) på de fleste europa- og alle riksvegene i Norge. For det øvrige vegnettet er det Nye veier, fylkeskommunene og kommunene som har ansvaret for å samle inn trafikkdata.
Trafikkdata blir brukt bl.a. for trafikkstyring, drift og planlegging av veger.
Statens vegvesen har laget et eget system «Trafikkdatasystemet» for innsamling, bearbeiding og publisering av trafikkdata. Avhengig av type trafikkregistreringsutstyr (stasjonær eller mobil) samles data inn på ulike måter. Dataloggere som står på faste stasjoner med kontinuerlig registrering, er oppkoblet direkte mot Trafikkdatasystemet i et lukket nett. Kommunikasjonen mellom dataloggerne og Trafikkdatasystemet foregår over OPCUA. Data fra stasjonære kontinuerlige stasjoner hentes inn med kun et par sekunders forsinkelse.
Del 1: Kjøper
Del 2: Prosedyre
Del 5: Delkontrakt
Del 8: Virksomheter
Del 10: Endring
Kunngjøringsinformasjon
Endringer i kunngjøringen (1)
- Gjeldende versjon25.08.2026du er her
- Original kunngjøring25.06.2026Åpne
Endringene er korte rettelser/oppdateringer fra oppdragsgiver. Original og alle versjoner er tilgjengelig her.
Sammendrag
Anbudsradar
Statens vegvesen (Kunden) ønsker en rammeavtale med én leverandør for levering av dataloggere for kontinuerlig trafikkregistrering på faste stasjoner. Dataloggerne skal sende trafikkdata til Trafikkdatasystemet via OPCUA (i lukket VPN/Datainnsamlingsnett). Avtalen har estimert behov ca. 160 dataloggere over avtaleperioden og opsjon på utskifting av ca. 80 eldre dataloggere. Rammeavtalen reguleres av SSA-R (rammeavtaletekst) og de enkelte avrop av SSA-K (kjøpsavtale) og evt. SSA-V (service for opsjon 2). Leverandøren må utvikle OPCUA-serveren og navneromskompatibilitet innen 6 måneder fra kontrakt signert; deretter leveranser i avrop med minimum 4 uker fra bestillingsdato. Kunden kan inngå direkteavrop i KGV (og overgang til Unit4 bestillingsløsning). Opsjon 2 kan gi service-/vedlikeholdsavtale med krav til remote feilsøk og support.
Krav til tilbudet
Anbudsradar
- Tilbyder må fylle ut Bilag 6 (Leverandørens besvarelse) basert på Bilag 1 (Kundens kravspesifikasjon) og Leverandørens besvarelse. Avvik/forbehold i Bilag 6 kan medføre avvisning.Kilde: Bilag 1 kapittel (Bilag 6 Leverandørens besvarelse)
- Leverandøren skal levere Bilag 2 (Kravtabell rammeavtale trafikkregistreringsutstyr) utfylt som del av tilbudet.Kilde: Bilag 1 kapittel 1.2 Krav til leveransen
- Leverandøren skal svare ja/nei på MÅ-krav i kravtabellen (Bilag 2) uten utdyping.Kilde: Bilag 2 [ARK: MÅ-krav]
- Leverandøren skal i tilbudet beskrive/oppgi oppfyllelse av E-krav samt nødvendige dokumentasjons-/referansekrav til E-krav (klima/miljø, brukbarhet, produksjon og transport, registreringskvalitet/parametere).Kilde: Bilag 2 [ARK: Funksjonelle krav], [ARK: Ikke funksjonelle krav], samt E-krav-arkene
- Leverandøren skal legge ved eksempel på utforming og plassering av QR-kode på datalogger (inkl. feilrettingskapasitet og størrelsekrav) som del av besvarelsen til MÅ-krav nr. 5.Kilde: Bilag 2 [ARK: MÅ-krav] Krav nr. 5
- Leverandøren skal i funksjonelle/ikke-funksjonelle krav gi planer/dokumentasjon som uttrykkelig kreves (f.eks. plan for OPCUA-server og navneromskompatibilitet, samt brukerveiledning og sensor-/restriksjonsdokumentasjon der aktuelt).Kilde: Bilag 2 [ARK: Funksjonelle krav] og [ARK: Ikke funksjonelle krav]
Innleveringsvilkår fra kunngjøringen
- Frist for forespørsel/tilbud
- 10.09.2026
- Språk
- norsk, English
- Elektronisk katalog
- Ikke tillatt
Tildelingskriterier
Anbudsradar
| Kriterium | Vekt | Beskrivelse |
|---|---|---|
| Pris | 40 % | Dokumentasjonskrav: Leverandøren skal legge ved utfylt prisskjema vedlegg 1 |
| K1 Klima og miljø | 30 % | Ikke nærmere beskrevet |
| K2 Kvalitet på utstyr | 30 % | Det vil bli vektlagt hvilket utstyr kontraktsgjenstanden leveres med utover minimumskravet til det spesifiserte minimumsutstyret. Dokumentasjonskrav: Leverandøren skal legge ved en beskrivelse av dokumentasjon av løsninger, arbeidsmetoder eller materialer kontraktsgjenstanden leveres med. Leverandøren skal dokumentere at tilbudt løsning eller tilbudt produkt oppfyller konkurransegrunnlagets funksjonskrav og kvalitetsnivå ut over dette. |
Viktige kontraktskrav
Anbudsradar
- Utvikle OPCUA-server og navneromskompatibilitet ferdig innen 6 måneder fra kontrakt signert av begge parter.Kilde: Bilag 1 (Leveringstid – tidsplan og tilhørende frister)
- Kommunikasjonskrav: All informasjonsflyt mellom datalogger og Trafikkdatasystem skal gå over OPCUA (inkl. RTDCE interface – OPCUA).Kilde: Bilag 1 kapittel A (Trafikkdatasystemet)
- Leveringstid per avrop: leveringstid minimum 4 uker fra bestillingsdato (leveringssted angis i hvert avrop).Kilde: Bilag 1 (Leveringstid og omfang vil bli avtalt i hvert enkelt avrop...)
- Opsjon 1 (SSA-K): Kunden har opsjon på å erstatte eldre dataloggere (ca. 85) og SSA-K brukes for alle avrop + opsjon 1.Kilde: Bilag 1 (Opsjoner)
- Opsjon 2 (SSA-V): Leverandør må beskrive service og vedlikehold for å opprettholde kvalitet på trafikkregistreringer; feilsøk i hovedsak remote; support med kontaktinfo og åpentider; SSA-V brukes for opsjon 2 (serviceavtalen varer utover rammeavtalens varighet).Kilde: Bilag 1 (Opsjoner)
- Datakvalitet: dataloggeren skal registrere minst 99 % av trafikken (og E-krav spesifiserer maks 1 % avvik).Kilde: Bilag 1 (Datakvalitet) og Bilag 2 [E-krav Kvalitet på utstyr] Krav nr. 1
- Registreringskrav: unik numerisk sekvensiell identitet for hver kjøretøypassering og tidsstempel i UTC millisekundformat; monotont økende sekvensnumre.Kilde: Bilag 2 [MÅ-krav] Krav nr. 6-7
- Tekniske MÅ-krav: CE-merking, 230V via stikkontakt, tydelig merking av porter, merking med MAC-adresse (QR+tekst), serienummer, trafikkantgruppe og antall felt; QR-kodekrav og krav om firmware-oppgradering/verifikasjon/oppstart etter strømbrudd; NTP-synk og min. daglig synk.Kilde: Bilag 2 [MÅ-krav] Krav nr. 1-5 og 8-14
- IP33-minimum for utstyr i skap og backup-batteri tilkoblingsmulighet (ringkabelsko 6,4 mm som standardkobling) der kundens valg mulig.Kilde: Bilag 2 [Ikke-funksjonelle krav] Krav nr. 2-4
- Testing etter avtaleinngåelse: OPCUA grensesnitt og datalagring må testes og godkjennes av Statens vegvesen før leverandøren kan levere dataloggere på avtalen (Del 2).Kilde: Testprosedyre (Del 2 – test av OPCUA grensesnitt)
Forbehold ved utdraget
Anbudsradar
- Dokumentgrunnlaget inneholder ingen eksplisitte leverandørkvalifikasjonskrav (økonomi/kapasitet/teknisk/faglig kvalifikasjon) i utdraget; det kan ligge i deler av konkurransegrunnlaget som ikke er med.
- Tildelingsformel/vekting mellom ulike E-krav fremgår ikke i detalj; teksten sier at beste leverandør får 10 poeng i skala 1-10, men uten eksplisitt samlet vekt/underkriterie-matrise.
- Leveringsdato/ikrafttredelsestidspunkt og eksakt kontraktsvarighet start/end er ikke fylt ut i utdraget (det fremgår generelt at rammeavtalen gjelder 2 år med opsjon forlengelse til total 4 år i SSA-R/Bilag 4-tekst).
Verdt å avklare med oppdragsgiver
Anbudsradar
Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.
I bilag 1 (kravspesifikasjon) står det at "OPCUA-serveren til dataloggeren skal være ferdig utviklet innen 6 måneder fra kontrakt er signert", men at "kravene til kommunikasjon mellom datalogger og Trafikkdatasystemet... ikke blir testet og evaluert i konkurransen, men må oppfylles før leverandøren kan levere dataloggere på avtalen". Kan Kunden bekrefte hva som er aksept-/leveranse-kriteriet før første leveranse i rammeavtalen (f.eks. prototypegodkjenning, TCK-godkjenning, eller dokumentert compliance), og om dette er knyttet til et bestemt tidspunkt i bilag 4/avtalens plan?
Hvorfor det er verdt å spørre: Leverandøren må forstå hva som faktisk utløser retten/plikten til å levere utstyr, og hvordan 6-måneders utviklingsmilepæl relaterer seg til godkjenning og test (TCK/TUAExpert). Dette påvirker fremdriftsplan og risikopris.
Kilde: SSA-R Rammeavtale trafikkregistreringsutstyr – Bilag 1: Leveringstid – tidsplan og tilhørende fristerI Bilag 4 fremgår det at leveringstid i hvert avrop skal være minimum 4 uker fra bestillingsdato. Kan Kunden presisere hva "bestillingsdato" er i praksis (dato for KGV-bestilling/ordrebekreftelse/EHF mottak i Unit4), og om 4 uker gjelder hele leveransen (inkl. strømforsyning, kabler, kobling til backup-batteri og eventuelle eksterne sensorer), eller kun dataloggerdelen?
Hvorfor det er verdt å spørre: Presisering av starttidspunkt og leveranseomfang er avgjørende for å prise logistikks-/produksjonsløp og for å unngå avviksrisiko.
Kilde: SSA-R Rammeavtale trafikkregistreringsutstyr – Bilag 1: Leveringstid – tidsplan og tilhørende frister / Bilag 2: Prosedyrer for tildeling av kontrakterOppdragsgiver beskriver at dataloggeren har innebygget OPCUA-server, og at Trafikkdatasystemet bruker OPCUA history read. I OPCUA-dokumentet står det at "When network is not available, the RTDCE must not buffer real-time events, but store them in the archive" og at "The RTDCE must archive data in a way that makes it possible to use history read at any time interval, also through hourly shift". Kan Kunden bekrefte hvilke praktiske begrensninger som legges til grunn for "not buffer real-time events" og "hourly shift" (f.eks. maksimal buffer-/lagringskapasitet, maksimum fravær fra nett som skal håndteres, og forventet vekslings-/fullstendighetslogikk for history read i avrop/operasjon)?
Hvorfor det er verdt å spørre: Leverandøren må vite krav til buffer/arkiv og varighet for kommunikasjonstap for å designe maskinvare, firmware og testopplegg. Dette påvirker både kost og risiko.
Kilde: INFO – RTDCE interface - OPCUA (Kravspesifikasjon) – "RTDCE buffer and history read"I OPCUA-dokumentet ("General OPC UA requirements") står det at RTDCE skal bruke sertifisert OPC UA Server SDK/Toolkit fra OPC Foundation (og at "The SDK must be named in the tender"), samt at "Each subscription must handle at least 100 monitored items". Kan Kunden bekrefte om det er tilstrekkelig at leverandøren angir hvilket sertifisert SDK/toolkit som brukes (produktnavn/leverandør), og om kravet "100 monitored items" gjelder per abonnement (subscription) i TCK-testen/NPRA-modellen eller totalt i enheten (og i så fall hva som menes med "handle" i denne konteksten)?
Hvorfor det er verdt å spørre: Utydelighet rundt hva som skal bevises i tilbudet og hvordan 100-monitored-items kravet skal etterleves kan medføre feilprising eller mangelfull besvarelse i bilag 6.
Kilde: INFO – RTDCE interface - OPCUA (Kravspesifikasjon) – "General OPC UA requirements" (ID 2 og ID 10)I OPCUA-dokumentet står det at address space "will be developed over time" og at "all alterations will be made known to the Contractor". Kan Kunden beskrive prosessen for endringer etter kontraktsinngåelse før/under produksjon (f.eks. tidsvarsel, krav til oppdatering av dokumentasjon/UA Modeler file, og om leverandøren får endringsavtale/kompensasjon dersom adresse-/node-endringer krever omarbeid/omprogrammering før levering eller godkjenning)?
Hvorfor det er verdt å spørre: Dette er en konkret risikofaktor for utviklingsprosjektet (moving interface). Leverandøren trenger endringsmekanisme og forventet praktisk styring for å prise.
Kilde: INFO – RTDCE interface - OPCUA – "OPC UA address space" (avsnitt om at address space utvikles over tid) / SSA-R rammeavtale – Bilag 4 (endringsmekanisme følger av SSA-R/SSA-K)Bilag 1 beskriver datakvalitet, bl.a. "Dataloggeren skal registrere minst 99 % av trafikken" og tabeller for nøyaktighet (presisjon/oppløsning) samt kvalitative parametere som "SpeedQuality" og "ClassQuality". Kan Kunden bekrefte hvordan disse kvalitetskravene praktisk verifiseres ved avrop (målemetode, testoppsett, hvilken akseptgrense gjelder, og om 99 % gjelder per stasjon, per datalogger, eller over en definert testperiode)?
Hvorfor det er verdt å spørre: Tydelig verifikasjonsmetode er nødvendig for at leverandøren skal kunne både dokumentere compliance og prise risiko knyttet til ytelse.
Kilde: SSA-R Rammeavtale trafikkregistreringsutstyr – Bilag 1: Datakvalitet (Tabell 1 og 2)I Bilag 2 (Prosedyrer for tildeling) står det at direkteavrop foreløpig gjennomføres i KGV, og at det i løpet av høsten 2026 vil foregå i Unit4 bestillingsløsning. Kan Kunden bekrefte hvilke konsekvenser dette har for leverandørens rutiner rundt ordreformat, frister for ordrebekreftelse uten ugrunnet opphold, og om det finnes særskilte frist-/kommunikasjonskrav som vil endres ved overgang til Unit4?
Hvorfor det er verdt å spørre: Operasjonelle forhold (ordrekanal og svarfrister) kan påvirke leverandørens leveransemargin og etterlevelse.
Kilde: SSA-R Rammeavtale trafikkregistreringsutstyr – Bilag 2: Prosedyrer for tildeling av kontrakter innenfor rammeavtalenOpsjon 2 gjelder service- og vedlikeholdsavtale (SSA-V) og beskriver at "Feilsøk skal i hovedsak gjøres remote" og at "I tilfelle dataloggeren og/eller sensorene må ha jevnlig service... vil Kunden demontere og sende utstyret til leverandøren". Kan Kunden spesifisere hva som anses som "remote" (f.eks. VPN-tilgang til Datainnsamlingsnettet, bruk av OPCUA for feilsøking, eller behov for fysisk besøk), samt typisk forventet kjøremønster for remote vs. fysisk service (f.eks. anslått andel i prosent eller forventet SLA)?
Hvorfor det er verdt å spørre: Vedlikeholds-/support-opsjonen kan gi betydelig prisforskjell. Leverandøren må forstå omfanget av remote support og hvilke forutsetninger Kunden faktisk stiller med på demobilisering.
Kilde: SSA-R Rammeavtale trafikkregistreringsutstyr – Bilag 1: Opsjoner (Opsjon 2) / Kapittel A-D (VPN-tilgang omtales)
Kurs og rådgivning fra redaksjonen
Gratis fagmøte – 30 minutter digitalt om aktuelle anskaffelsestemaer.
Se datoer →Kurs: Hvordan vinne anbud – praktisk kurs for deg som skriver tilbud.
Les mer →Rådgivning
Ta kontakt →