Vi använder begreppet IoT i bred bemärkelse här och inkluderar även ”statiska” data. Även så kallade öppna data inkluderas. Från ett tekniskt plattformsperspektiv är öppna data en delmängd av delade data där accessformen är öppet för alla. Ramverket inkluderar alltså i princip alla typer av data som kan knytas till ett objekt. Med minimiramverk menas en minsta gemensam nämnare som tillfredsställer alla städers tankar eller konkret arbete runt plattformsarkitektur. Vi använder oss här av en treskiktad modell. Längst ned ett datalager där data kan vara från en sensor (eller snarare ett sensornätverk), en databas eller en annan plattform. I mitten en dataväxel (även kallad IoT core, middleware, datamäklare, tjänstemäklare, eller liknande). Överst databearbetning, alltså typiskt tjänster. Mellan datakälla och dataväxel finns det ett gränssnitt i form av datamodeller, och mellan dataväxel och processering är gränssnittet API (application programming interface). Det är inget kontroversiellt i bilden, så ser i princip alla data- och IoT-plattformar ut om man abstraherar bort alla icke-grundläggande funktioner.

Man bör vara uppmärksam på att man hamnar i en potentiell inlåsning om man tillåter en aktör att vara aktiv i flera skikt samtidigt, t ex om plattformsleverantören erbjuder tjänster på sin egen plattform eller inte delar med sig av data.

Beroende på målgrupp och vilka funktioner man vill inkludera kan bilden av en data/IoT- plattform se ut på många olika sätt; denna bild är alltså ritat utifrån principen om att separera de olika lagren. En IT-arkitekt hade typiskt ritat en bild som illustrerar dataflöde från vänster mot höger, en tjänsteleverantör hade fokuserat mycket mer på övre delen, etc.

Bilden är långt ifrån en komplett produktionsplattform. Det fattas många funktioner, men det finns idag ingen konsensus för hur dessa ska lösas. Det behövs accesskontroll, marknads­plats, säkerhetslösningar på olika nivåer, lokal och global lagring av data, lokal processering för att t ex rensa data, etc. Kommersiella leverantörer har egna lösningar, men de skiljer sig åt. Idén är under projektet att tillsammans identifiera vilka extra funktioner som eventuellt kan göras nationella, alltså användas i många städer, och vilka som är lokala eller kanske knutna till specifika tjänster.

Vi behöver data som är tillgängliga OCH som har hög kvalitet – och det handlar inte bara om öppna data; det handlar minst lika mycket om data med någon typ av restriktioner för vem som får använda det eller hur det får användas.

Sverige – som brukar hamna i topp när det gäller internationella rankningar om digitalisering – är som nation ganska dålig på att arbeta med data i offentlig sektor. En indikator på hur dålig finns i OECDs Open Government Data Report där Sverige rankas bland de absolut sämsta i OECD.

Så hur ska vi agera då? Innan data överhuvudtaget kan förädlas till olika typer av nytta måste data kunna tillgängliggöras för de som ska förädla data!

En kommun (eller annan offentlig aktör – eller privat aktör för den delen) måste tillägna sig förmågan att kunna samla in data och tillgängliggöra data på ett kontrollerat sätt.

City as a Platform fokuserar främst på de grundläggande tekniska förutsättningarna men projektet berör även de organisatoriska förutsättningarna och till mindre grad affärsmodeller. Idén i City as a Platform är att om kommunerna samsas om den tekniska förmågan, då blir det mycket enklare att komma igång med de övriga komponenter samt att se till att data faktisk blir förädlat till olika typer av nytta!

Det ska påpekas att City as a Platform inte adresserar alla tekniska förutsättningar som behövs för att kunna samla in och tillgängliggöra data. Vi jobbar exempelvis inte med sensornät vilket är en nyckelkomponent för IoT-data. Dessutom adresserar vi inte heller molnproblematiken, alltså hur och var man lagrar och processerar data. Även säkerhetsmekanismer på olika nivåer abstraherar vi bort till viss grad, men säkerhet måste såklart integreras in i alla lösningar och processer helt från början.

Tekniska förutsättningar – referensarkitektur

City as a Platform förespråkar att följa ett minimiramverk för en data/IoT-plattform. Vid upphandling och införande av en plattform räcker det inte att peka på ett minimiramverk, det kan behövas en konkret referensarkitektur som en leverantör kan förhålla sig till och som man kan integrera mot kommunens olika verksamhetssystem och integrationsplattformar.

City as a Platform har tillsammans med SKR och Inera tagit initiativ till en arbetsgrupp ”RefArk” inom ramen för Ineras Arkitekturgemenskap som ska definiera en referensarkitektur för IoT.

Alla kommuner och regioner kan delta i arbetsgruppen (vilket gäller alla andra arbetsgrupper inom Arkitekturgemenskapen) men det finns idag en hög representation av CaaP-kommuner. Samma referensarkitektur kan med fördel appliceras inom övriga verksamheter inom en kommun eller region, inte bara inom ”smart city”. En referensarkitektur blir en nyckelkomponent för en kommuns tekniska förutsättningar och förmågor att kunna samla in och tillgängliggöra IoT-data!

Beroende på hur arbetet i RefArk utvecklas kommer det att bli mer tydligt vem som eventuellt ska ansvara för ett ramverk/en referensarkitektur/standarder på nationell nivå således att det finns en förvaltningsmodell på plats innan City as a Platform avslutas.

Organisatoriska förutsättningar – Normerande informationsklassning genom ”Klassa för IoT”

En observation inom City as a Platform är att även om de tekniska förutsättningarna för att kunna dela på data är på plats (t ex genom en IoT-plattform) då fattas ofta de organisatoriska förutsättningarna att kunna dela på data. De organisatoriska förutsättningarna inkluderar äganderätt av data som något helt grundläggande, alltså t ex att man kräver äganderätt i en upphandling och att det tydliggörs vem i organisation som är data/informationsägare.

Informationsägaren är den som dikterar vem som får komma åt data och på vilka villkor. För att kunna göra detta på ett kontrollerat och skalbart sätt behövs någon typ av informationsklassning av varje datakälla. Informationsklassningen inkluderar risk-/säkerhets-/konsekvensanalyser av vad som kan hända med data om det görs tillgängligt för andra. SKR tillhandahåller verktyget ”Klassa” som kan användas vid informationsklassning. Detta verktyg har fram till idag varit systemcentrerat baserat på uppfattningen att man på förhand typiskt vet i vilket system data ska användas. Men om man systematiskt vill kunna göra data tillgänglig för andra vet man ofta inte i vilket system data ska användas. SKR utvecklar under 2020 en uppgraderad version ”Klassa 4.0” bättre anpassad för hantering av de informationstillgångar vi definierar inom IoT data/informationscentrerat.

Parallellt med detta har SKR tillsammans med City as a Platform tagit initiativ till att kravställa och utveckla ett normgivande stödverktyg ”Klassa för IoT” som specifikt fokuserar på IoT-data.

Verktyget testas bland annat tillsammans med kommunerna i City as a Platform för att fånga in feedback från kommuner som har kommit långt i sin IoT-resa. Klassa för IoT kommer i kombination med Klassa 4.0 bli nyckelkomponenter för en kommuns organisatoriska förutsättningar och förmågor att kunna tillgängliggöra IoT-data!

Observera att det som beskrivs här är helt grundläggande organisatoriska förutsättningar för att överhuvudtaget kunna tillgängliggöra data, sedan tillkommer det mycket mer omfattande organisatoriska utmaningar när man ska börja använda och förädla data i verksamheten.

Inom City as a Platform arbetar vi utifrån antagandet att man som minimum måste standardisera datamodeller och API (application programming interface). Vi har från början av projektet poängterat att vi vill utgå ifrån Fiware, främst i form av just datamodeller och API, eftersom vi inte har velat exkludera leverantörer som inte följer hela Fiware-komplexet.

Fiware är ursprunglig en satsning som finansierades av Europeiska Unionen som ett svar på den amerikanska interdominansen. Fiware kan ses som ett bibliotek av jättemånga open source-byggblock med vilka man kan bygga en komplett IoT-plattform eller bara delar av den. I teorin ska det vara ungefär som att bygga med Lego men i praktiken krävs ofta en del integration för att få allt att fungera. Det har investerats hundratals miljoner euro i Fiware genom bland annat multipla forskningsprojekt, och man kan diskutera om det var det mest effektiva sättet att bygga upp europeisk internetkompetens. Nu är Fiware frikopplat från EU genom Fiware Foundation som är finansierat av sina medlemmar.

Det blev dock för oprecist och begränsande att i projektet peka på datamodeller och API från Fiware. Vi pekar därför i City as a Platform på standarden NGSI (next generation service interface). Det är vad den europeiska sammanslutningen Open Agile Smart Cities (OASC) också rekommenderar i sina så kallade minimum interoperability mechanisms (MIMs). Dessa MIMs påminner mycket om ramverket som City as a Platform förespråkar. Det finns olika versioner av NGSI som t ex ETSI:s standard ”Context Information Management (CIM); NGSI-LD API”.

NGSI är egentligen en standard för ett API. Den tillåter JSON-baserade datamodeller men inte alla JSON-datamodeller; det finns t ex vissa attribut som måste vara inkluderade för att säkerställa interoperabilitet.

Det finns olika ”familjer” av datamodeller som accepterats av NGSI. Det inkluderar alla Fiware-datamodeller. Dessutom accepteras datamodeller från schema.org, och man kan utveckla sina egna datamodeller som stödjas av NGSI – t ex genom att utgå ifrån en mall för Fiware-datamodeller. Även projektet SynchroniCity har utvecklat flera datamodeller som följer NGSI.

En Fiware-baserad plattform är ”fött” till att kunna följa NGSI men i princip vilken som helst annan plattformsleverantör kan välja att integrera stöd för NGSI. Genom att peka på NGSI i stället för att peka på ”datamodeller och API från Fiware” åstadkommer vi en mer tydlig och samtidigt mer inkluderande rekommendation – som dessutom är behörigt standardiserat.

Öppenhet och öppen plattform

För en teknikleverantör betyder ”öppet” ofta att man följer befintliga standarder och undviker proprietära lösningar. Utan standarder, ingen interoperabilitet, och standarder är absolut ett stort och nödvändigt steg mot öppenhet. För en behovsägare handlar öppenhet dock även om att man kan byta ut komponenter i en plattform och inte hamna i en inlåsningssituation, vilket är bredare än att alla standarder följs och att det finns interoperabilitet.

En plattformsleverantör kan följa standarder på alla ställen där man kan koppla in sensorer eller tjänster, men om den leverantören av någon anledning inte vill eller kan låta en tredjepart leverera sina tjänster på sin plattform är det inte öppet. Trots att man följer alla standarder gör man ett slutet system som en del av sin affärsmodell. Öppenhet för behovsägare betyder alltså typiskt möjligheten för att på ett enkelt sätt kunna lägga till eller byta utrustning eller tjänst från tredjepartsleverantör. På samma sätt avser öppen plattform att det finns mekanismer för att åstadkomma denna öppenhet.

I en upphandlingssituation måste behovsägaren alltså kräva öppenhet (om det är så att man önskar öppenhet) samt även definierar vad man menar med detta. Annars finns det stor risk för inlåsning i alla fall. Observera att de flesta plattformsleverantörer med respekt för sig själv argumenterar för att de har en ”öppen plattform”, men ibland betyder det att man använder sig av öppen källkod eller att man följer standarder – och det är alltså INTE tillräckligt för att säga att man har en öppen plattform enligt definitionen här.

Öppen källkod

Open source eller öppen källkod är programkod som kan användas och modifieras av vem som helst. Det finns många fördelar med öppen källkod men det ska dock inte förväxlas med en öppen plattform. En öppen plattform kan innehålla helt proprietär kod; det viktiga är just att alla gränssnitt mot plattformen är väldefinierade. På samma sätt finns det ingen garanti för att en plattform byggt på öppen källkod kan leda till ovan definierade öppenhet.

Öppna och delade data  

Med öppna data avses digital information som är fritt tillgänglig utan inskränkningar i form av t.ex. upphovsrätt och patent (intellectual property rights, IPR). Allt fler länder och städer tillgängliggör öppna data genom en webbportal, det kan vara data som trafikinformation, dagistider, geodata, etc. Öppna data är fritt att använda för vem som helst utan restriktioner, även för kommersiella applikationer. Öppna data och öppna plattformer är två helt olika saker:  Öppna data kan vara en delmängd av det som tillgängliggörs av en öppen plattform, men en öppen plattform kan också möjliggöra data som är belagt med olika typer av restriktioner.

Ofta i debatten missförstås begreppet öppna data på et sättet att det finns datakällor som egentligen inte är fritt användbara för alla. Så snart det finns restriktioner är det inte öppna data. Delade data är alltså mängden av öppna data samt data med restriktioner. Och det man ofta menar i debatten är egentligen delade data, alltså data som är tillgängliga med eller utan restriktioner. T ex är hälsodata mycket sällan öppna data om de inte är helt anonymiserade.

Restriktioner i öppenheten                 

Data som i sig själv eller i kombination med annan data kan äventyra integriteten av en individ, en infrastruktur eller en organisation, och dessa typer av data bör aldrig publiceras som öppna data. Två ”ofarliga” datakällor kan genom att kombineras skapa ett integritetshot. Man kan med viss rätt argumentera för att det är omöjligt att säkerställa att det inte i framtiden kan dyka upp en ny datakälla som kombinerat med befintlig datakälla leder till ett integritetshot. Men det skulle i så fall betyda att det blir omöjligt att publicera öppna data vilket i sin tur omöjliggör innovation baserad på öppna data. Som med så många andra i livet gäller det att hitta rätt balans.

Även data som har ett ekonomiskt värda som dataägaren vill profitera på bör inte publiceras som öppna data. Men såväl data som är integritetshotande och som har ett ekonomiskt värde kan publiceras som delad data – fast då med restriktioner i tillgänglighet och användande.

Man kan hamna i en situation där det inte är möjligt eller önskvärd att upphandla en öppen plattform. Marknaden för öppna plattformar är fortfarande omogen och det kan vara nödvändigt att tillåta en viss grad av inlåsning för att en försäljning är tillräckligt attraktiv för plattformsleverantören. Detta kommer troligen att förbättres på en mognare marknad med flera leverantörer och bättre konkurrens.

Det kan även vara så att en behovsägare inte är intresserad av en öppen plattform för att man vill ha en snabb utrullning och därför inte orkar bry sig om den tekniska förmåga som krävs för att kunna kravställa tillräckligt bra för att säkra öppenhet. En sådan lösning kommer säkert på kort sikt att vara billigare än en öppen plattform, men det är viktigt att behovsägaren i så fall förstår de långsiktiga konsekvenser i form av inlåsning, högra kostnader och brist på kontroll.