Tecken finns på att det objektorienterade paradigmet börjar tappa sinstatus som den oomstridda lösningen inom systemutveckling. Nya idéerkommer in och ställer grundläggande programmeringsprinciper påända. Vad kan ett deklarativt förhållningsätt tillföra och vad innebär detatt programmera funktionellt? Variabler är en viktig komponent i denprogrammering som huvudsakligen bedrivs idag. Variabler tillhör detimperativa paradigmet i vilket programmeraren i hög grad beskriverhur beräkningar skall utföras av datorn. Detta står i kontrast till detdeklarativa paradigmet – i vilket funktionell programmering normaltplaceras – där man har en högre abstraktionsgrad, saknar variabler ochendast beskriver att något skall göras – inte hur. I funktionellprogrammering kan inte något tillstånd i samma bemärkelse som iimperativ – procedurell eller objektorienterad – programmering finnas.Upprepningar måste göras med rekursion och program ärdeterminerade. Både fördelar och nackdelar finns med detta, det blirlättare att resonera kring ett program men samtidigt kan sidoeffekter,som att skriva något till en fil, inte förekomma i rent funktionellaprogram. Eftersom detta är en vanligt förekommande uppgift idatorprogram idag måste det hanteras på något sätt. Att kombinerafunktionella och objektorienterade språk innebär visserligen enkompromiss där man förlorar en del av de fördelar som finns med rentfunktionella program men är samtidigt en naturlig utveckling från detobjektorienterade arbetssätt vilket för närvarande är så dominerande.Följande uppsats ämnar att förklara den funktionella programmeringen,redogöra för de aspekter som gör den intressant och beskriva dess platsi framtidens program- och systemutveckling.Tecken finns på att det objektorienterade paradigmet börjar tappa sinstatus som den oomstridda lösningen inom systemutveckling. Nya idéerkommer in och ställer grundläggande programmeringsprinciper påända. Vad kan ett deklarativt förhållningsätt tillföra och vad innebär detatt programmera funktionellt? Variabler är en viktig komponent i denprogrammering som huvudsakligen bedrivs idag. Variabler tillhör detimperativa paradigmet i vilket programmeraren i hög grad beskriverhur beräkningar skall utföras av datorn. Detta står i kontrast till detdeklarativa paradigmet – i vilket funktionell programmering normaltplaceras – där man har en högre abstraktionsgrad, saknar variabler ochendast beskriver att något skall göras – inte hur. I funktionellprogrammering kan inte något tillstånd i samma bemärkelse som iimperativ – procedurell eller objektorienterad – programmering finnas.Upprepningar måste göras med rekursion och program ärdeterminerade. Både fördelar och nackdelar finns med detta, det blirlättare att resonera kring ett program men samtidigt kan sidoeffekter,som att skriva något till en fil, inte förekomma i rent funktionellaprogram. Eftersom detta är en vanligt förekommande uppgift idatorprogram idag måste det hanteras på något sätt. Att kombinerafunktionella och objektorienterade språk innebär visserligen enkompromiss där man förlorar en del av de fördelar som finns med rentfunktionella program men är samtidigt en naturlig utveckling från detobjektorienterade arbetssätt vilket för närvarande är så dominerande.Följande uppsats ämnar att förklara den funktionella programmeringen,redogöra för de aspekter som gör den intressant och beskriva dess platsi framtidens program- och systemutveckling. / There are signs that the object-oriented paradigm is beginning to lose itsstatus as the undisputed answer in system development. New ideas arearriving and they are flipping fundamental programming principlesupside down. What can a declarative approach bring and what does itmean to program in a functional fashion? Variables are an importantcomponent in the type of programming that is generally conductedtoday. Variables belong to the imperative paradigm in which theprogrammer to a large extent describe how calculations are to bepreformed by the computer. This is in contrast to the declarativeparadigm – in which functional programming is usually placed – wherethe level of abstraction is higher, variables are missing and where youonly describe that something is to be performed – not how. In functionalprogramming there cannot be any state in the same sense as inimperative – procedural or object-oriented – programming. Repetitionhas to be performed with recursion and programs are deterministic.There are both benefits and disadvantages with this, reasoning about aprogram is easier but at the same time there cannot be any use of sideeffects,like writing something to a file, in a purely functional language.Since that is a common task in computer programs today the dilemmahas to be dealt with in some way. Combining functional and objectorientedlanguages does mean making a compromise where some of thebenefits of purely functional programs are lost but it is also a naturalevolution from the object-oriented methods that are currentlydominating. The following thesis will show what functionalprogramming is, explain which aspects make it interesting and describeits place in the program and system development of the future.There are signs that the object-oriented paradigm is beginning to lose itsstatus as the undisputed answer in system development. New ideas arearriving and they are flipping fundamental programming principlesupside down. What can a declarative approach bring and what does itmean to program in a functional fashion? Variables are an importantcomponent in the type of programming that is generally conductedtoday. Variables belong to the imperative paradigm in which theprogrammer to a large extent describe how calculations are to bepreformed by the computer. This is in contrast to the declarativeparadigm – in which functional programming is usually placed – wherethe level of abstraction is higher, variables are missing and where youonly describe that something is to be performed – not how. In functionalprogramming there cannot be any state in the same sense as inimperative – procedural or object-oriented – programming. Repetitionhas to be performed with recursion and programs are deterministic.There are both benefits and disadvantages with this, reasoning about aprogram is easier but at the same time there cannot be any use of sideeffects,like writing something to a file, in a purely functional language.Since that is a common task in computer programs today the dilemmahas to be dealt with in some way. Combining functional and objectorientedlanguages does mean making a compromise where some of thebenefits of purely functional programs are lost but it is also a naturalevolution from the object-oriented methods that are currentlydominating. The following thesis will show what functionalprogramming is, explain which aspects make it interesting and describeits place in the program and system development of the future.

Advanced automatic testing is very important in development and research within the vehicle industry. Hardware-in-the-loop (HIL) systems give the ability to validate Electronic Control Units (ECUs) based on software simulation without gathering all of the physical hardware. This enables testing by providing inputs and examining the corresponding outputs of the ECUs in a simpler and safer way than in traditional physical testing. HIL offers the advantage that we can verify and validate the functions of ECUs prior to full-scale hardware production. On the contrary, because HIL systems are normally released as general-purpose test beds, it takes time to embed them into the current system. Additionally, the question of how to fill the gap between the HIL and the test environment is even more critical when the test bed is expected to be used for a long period of time without modifications. Furthermore, HIL systems are precious. It is not practical and will be considered as a waste of resource if it is used exclusively by testers. Scania’s RESI group uses Client-Server architecture to make it more flexible. The HIL system is hosted at server side while the testers operate it at client side. This architecture enables different implementations of client and server as long as a same protocol is applied, but this still does not solve the problem that the HIL is not always accessible when the testers want to debug their scripts. The testers want to find a solution to achieve this goal offline (without servers). To solve the problem, we first investigated which programming languages are used in the industry. Without doubt, there is no dominant language that ideally suits all situations, so secondly, we developed a new test environment. The new environment including “Dummy Mode” and “Mat Mode” is able to provide script validation service on basic and logic levels without servers. The result shows the Dummy mode is able to reach a higher detection rate (99.3%) on simple errors comparing to the current environment (81.3%). By reproducing and reusing the result of HIL system, Mat mode is able to identify logic errors and provide better assistance when the logic errors are found. In general, the proposed environment is able to show a better way of using HIL which makes the whole system more efficient and productive. / I fordonsindustrin ställs stora krav på avancerad automatiserad testning. För att utvärdera Electronic Control Units (ECUs) används så kallade Hardware-In-the-Loop-system (HIL) för att simulera den omkringliggande hårdvaran. Detta möjliggör enklare samt säkrare testning av ECU-komponenterna än vid traditionell fysisk testning. Med hjälp av HIL kan ECUs testas innan en fullskalig produktion sätts igång. Då HIL-system vanligtvis utvecklas för ett brett användningsområde kan det ta tid att skräddarsy dem för ett specifikt system. Ett annat viktigt problem vi ställs inför är skillnaderna mellan HIL-systemet och testmiljön, då testfallen förväntas att användas en längre tid utan förändringar. Vidare är HIL-system kostsamma. Det anses vara varken praktiskt eller ekonomiskt att låta HIL-system enbart användas av testare. Scanias RESI-grupp använder en klient-server-arkitektur för att åstadkomma flexibilitet HIL-systemet körs på serversidan medan testarna arbetar på klientsidan. Den här typen av arkitektur öppnar upp för olika implementationer på klient- samt serversida, förutsatt att samma kommunikationsprotokoll används. En nackdel med den nuvarande lösningen är att HIL-systemet inte alltid finns tillgängligt när testarna vill felsöka deras programskript. Testarna vill hitta en lösning där det går att utföra felsökningen lokalt, utan tillgång till servrar. För att kunna lösa problemet undersöktes först vilka programmeringsspråk som används inom industrin. Undersökningen visar på att det finns inget programmeringsspråk som är idealt för alla ändamål. Vidare utvecklades en ny testmiljö som tillhandahåller testlägena "Dummy Mode" samt "Mat Mode". Testmiljön kan användas för att validera programskript på grund- och logiknivå utan att kommunicera mot servrar. Resultatet visar att "Dummy Mode" detekterar upp till 99.3% av enklare typ av fel än motsvarande 81.3% i nuvarande testmiljön. Genom att reproducera och återanvända resultat av HIL-systemet kan “Mat Mode” identifiera logikfel samt ge en bättre indikation om vad felen innebär. Generellt sätt kan den föreslagna testmiljön visa på ett bättre användande av HIL, som gör hela systemet mer effektivt och produktivt.