2025 börjar lida mot sitt slut. Vår omvärld är dock fortsatt full av utmaningar för företag och individer. Addalot skänker även i år pengar till välgörenhet istället för julklappar.

Vi uppskattar SOS-Barnbyar och deras verksamhet för barn och deras uppväxt och i år fokuserar de på att få barn i utsatta områden tillbaka till skolan . Vi hoppas på ett gott slut på 2025 och ser med tillförsikt mot 2026 – fullt av nya möjligheter!

VARMA HÄLSNINGAR FRÅN ALLA OSS PÅ ADDALOT

This years SCSSS was run as an one day workshop within the large SafeComp conference.

Below follows a summary with some personal highlights from the presentations two keynotes and six presentations.

Please check the conference web for access to all presentations

The workshop kicked off with the keynote, “Assuring Safety in the Face of the Unpredictable” by Mario Trapp, Fraunhofer. A main concept was that you had to take into account a triad of aspects when working with safety for new AI systems:

Towards the end of his talk he looked at the potential analogy of a set of intelligent systems interacting with each other and with humans to a society, where the systems could be governed by rules and laws similar to our current society.

William Zeng, from Roben with his presentation “Automotive Overview on System Safety Standards and Practices for ICVs and NEVs in China: A different approach”  gave a very interesting insight into the fantastic dynamism of the Chinese car industry, how they had in a very short time become a major driver in the industry. It is well worth to look a the detailed examples presented in the slides. Here is just one example of Xiaomi entry into the car market:

Michael Wagner from ECR.AI “Embracing Change: LLM Use in Safety Engineering” first gave an overview of possibilities and pitfalls with LLM models:

Then he looked at the possibility to use formal proof checkers to check the output of LLM models.

Lunch was served together with all the other participants from SafeComp.

The afternoon started with a tutorial by Hans Liwång, KTH/Försvarshögskolan on “Interaction between technical and social system for the defense and security”. Hans started with observations about the importance of training and preparedness for survivability in naval warfare based on the Falkland conflict. The military safety is always a balance between safety and being able to continue to operate and achieve the target. There is no safe state as for a passenger car when standing still.

He also pointed out the value of giving people the ability to utilize the systems outside the safety limits in emergency situations, which might run contrary to how we think about safety to always keep the system within safe operational conditions.

AI Safety Assurance in the Automotive Domain – Standards Mapping and Application for an AI-Based SoC Estimation Function by Fredrik Warg; RISE gave an overview of how AI and safety research and standards have exploded in the last years.

Ali Nouri, Volvo Cars talked about “AI-enabled DevSafeOps for Autonomous Driving Software”. I was specially impressed by the breath of Ali’s research into how AI would impact all aspect of safety development. It will be interesting to follow this research in the future.

Filip Strand, KTH talked about his PH.D. work on Countering wildfire risk with AI-enabled sensor platforms so that the machines could avoid stones etc. that could lead to sparks causing fires. One major problem here was to create enough training data of relevant terrain that is labeled.

One idea that came up in the discussion was to rather use a program to generate images to train on. This should be possible as there is a limited number of elements in the terrain, however they have infinite many shapes and are randomly distributed. The generator could generate a labeled image that the IA could train on and as it is already labeled there is no “human” interaction.

Adapting ISO 21448 SOTIF for Mobile Machinery: A Forestry Automation Case Study by Aria Mirzai, RISE looked at applying SOTIF to  a Shuttle transporting logs from a harvester along pre-mapped forest roads to drop-off point.

The workshop ended with a buffet receptions at the Stockholm Townhall sponsored for SafeComp by Stockholm City. Here our foreign guests could try out most Swedish specialties; pickled herrings, meat balls, graved salmon and many more.

Lunds Tekniska Högskola LTH kommer genom en donation från företaget Addalot att inrätta ett stipendium inom området software engineering (programvaruteknik). Donationens avsikt är att hedra minnet av Q-Labs (numera kallade Addalot) alltför tidigt bortgångne grundare Geir Fagerhus.

Syftet med stipendiet är att belöna särskilt framstående examensarbeten som kopplar samman forskning inom software engineering med konkreta behov i industrin.

Geir Fagerhus, som startade Q-Labs i Lund 1989,  var en entreprenör och pionjär med en unik förmåga  att identifiera och realisera affärsmöjligheter inom software engineering.

Geir hade också ett stort intresse av att koppla samman industri med akademin och ”bridging the gap” var en av hans slogans. Som en del av denna strategi etablerade Q-Labs kontor nära universitet och organisationer som var framstående inom programvaruteknik som Fraunhofer Institute i Kaiserslautern och universiteten i Lund och Maryland.

Han etablerade också samarbeten med några av världens vid den tiden mest framstående forskare (Harlan Mills, Victor Basili, Dieter Rombach, Bill Curtis och Claes Wohlin) och etablerade en ”rådgivande styrelse” för Q-Labs, där många av dem hade en plats. Vidare lyckades Geir skapa nyckelroller för Q-Labs i europeiska forskningsprojekt, t.ex. REBOOT och PERFECT.

Geir var alltid på jakt efter nya tekniker och att omsätta dessa i praktisk nytta. Detta skedde då ofta i direkt samarbete med grundarna av teknikerna. Detta ledde till att Q-Labs introducerade modeller som Cleanroom Software Engineering och CMM för Ericsson och andra kunder.

Stipendiet är riktat till studenter på LTH, det universitet som Q-Labs under åren hade störst haft mest utbyte med, och kommer att delas ut årligen under minst fem år. Pristagare blir den/de som genomfört det examensarbete i datavetenskap med inriktning mot software engineering och som på bästa sätt återspeglar Geirs anda. Prissumman är på 10 000 kr per examensarbete och kommer att delas ut på LTH:s examenshögtid.

Bedömningskriterier för stipendiet är:

• Software engineering relevans – integrera förvärvad kunskap
• Industrirelevans – identifiera och konkretisera behov i industrin
• Ingenjörsmässighet- hantering av: frågeställning, balans i teori/praktik och informationskällor
• Presentation – pedagogisk disposition

En bedömningsgrupp med två företrädare från institutionen för datavetenskap och en representant från Addalot föreslår och motiverar beslut om pristagare. LTH:s rektor beslutar om pristagare. Examensarbeten avslutade under 2025 kommer vara de första att komma på fråga för detta stipendium.

The Automotive SPICE® (A-SPICE) framework has established itself as a critical process capability model within the automotive industry. It provides best practices for structured system development.

A-SPICE has gained widespread popularity among Original Equipment Manufacturers (OEMs) and Tier 1 suppliers, who often rely on A-SPICE assessments to evaluate the capabilities of their suppliers.

Version 4.0 of A-SPICE was released late 2023. In short, the new version includes clean up, removing unused areas and harmonizing terms, and strengthening of the plug-in concept, adding two new concepts “hardware” and machine learning” as complement to the existing software process group.

Key changes

• Slimline through of remove process areas that were not used
• Strengthen the plug-in concept with the addition of hardware and machine learning (HWE / MLE) that can replace or complement software (SWE).
• Detailed improvement
  • Some model adjustments
  • Slimline generic practices on CL3
  • Improve language
  • Simply some aspect

Removal of process areas

Ten process areas have been removed. They belong to the categories of acquisition (six process areas), support (three process areas) and supply (one process area). Theses process areas were seldom used so these changes that at first appear to be large, in reality is rather small.

Figure 1: A-SPICE version 3.1 with the ten removed process areas market

Plug in concept

To make the A-SPICE model more relevant for the industry three new process groups with in total ten new process areas have been added. The new process groups are:

• HWE (hardware engineering).The new version adds four processes for hardware development (HWE.1 – HWE.4), which are key for development of mechatronic systems. Even though the software part is growing, hardware plays a significant part of automotive development
• MLE (machine learning engineering). A-SPICE 4.0 includes four processes (MLE.1 – MLE.4) related to machine learning engineering. These processes focus on developing and integrating AI and data-driven technologies into automotive systems.
  In addition to these four process areas another process area related to machine learning data management has been added to the support category (SUP.11). This process addresses the need for effective data handling throughout the machine learning lifecycle, from collection and storage to processing and analysis.
• VAL (validation process). A new validation process (VAL.1) has been introduced to ensure that the overall system meets its requirements and performs as expected. This process is close the loop to stakeholder requirements and focus to secure successful “intended use” .

Figure 2: A-SPICE version 4.0 with the added ten process areas market

Scoping A-SPICE 4.0

With this new version scoping has become more intriguing. Before there was basic and extended scope and the only process area that was possible to de-select was ACQ.4. In version 4 there are three different scope types.

• Base: The core or the base of A-SPICE 4.0 are five process areas that always shall be applied
• Plug-in: minimum one of the plug ins must be selected: SYS/SWE/HWE/MLE
• Flex: the flex process areas are optional and can be added as appropriate

Figure 3: A-SPICE version 4.0 with the different process areas marked with scope type

Each organization need to analyse their scope. For A-SPICE assessments the sponsor defines the scope. BASE is always mandatory, then minimum one of the PLUG INS must be selected and finally the FLEX process areas shall be applied as relevant. ACQ.4 supplier monitoring and SPL.2 Product release will likely be the most applied process areas followed by MAN.5 Risk management.

Examples:

1. Former VDA scope: BASE + SYS + SWE
2. Electronic development: BASE + HWE
3. Development of software for road sign interpretation: BASE + SWE + MLE
4. Software development: BASE + SWE

In all cases FLEX additions might be relevant.

Figure 4: The three types of categories for scoping A-SPICE process areas

Detailed Changes

The detailed changes include many aspects like: model adjustments, improved language for increased understanding and slim lining some base/generic practices. Some changes will have significant impact on organizations working to meet A-SPICE expectations.

• Strategies moved from CL1 to be applicable for all process at CL2. In version 3.1 all verification process areas and the supportive process areas expect that a strategy directs the process area. This was often over interpretated and CL2 expectations was brought into CL1. The base practice with “strategy” has now been removed and instead GP2.1.1: “Identify the objectives …” is replaced by “Identify the objectives and define a strategy for the performance of the process”. As a consequence, all process areas at CL2 are expected to have a strategy. As a result, CL1 becomes more of doing and CL2 more repeatable!
• Evaluation of architectural alternatives (SYS.3.BP5, SWE.2.BP6) has been simplified to that “chosen architecture must be justified”. In many situations there is only one architecture alternative, based on legacy or customer requirements, which made the old practice less meaningful.
• Evaluate software detailed design (SWE.3.BP4) has been removed. It is covered by GP2.2.
• No specific base practice for “Verification criteria” (SYS.2.BP5, SWE.1.BP5) But it is instead included (or hidden) in “defined characteristics for requirements” (SYS.2.BP1, SWE.1.BP1) which in v4.0 include verification criteria.
• SW integration testing (SWE.5), now include both integration testing as well as component testing.
• Traceability and consistency merged/combined. BPs for traceability and consistency have been merged (affects all engineering and verification processes). Focus is to ensure consistency; traceability is one enabler but not mandatory to review or document
• Restructuring Generic Practices (slim lining)

• • GP2.1.3 + GP2.1.4 merged into (monitor and adjust)
  • GP3.1.1+ GP3.1.2+ GP3.1.3 (roles/responsibilities/authorities) merged into “maintain standard process”
  • GP3.2.2+ GP3.2.3+ GP3.2.4 (Human resource) merged into “ensure required competencies for the defined roles”
  • GP3.2.4 (information)+ GP3.2.5 merged into “ensure required resources to support the performance”

In summary 4 generic practices are removed, which means that if you assess 15 process areas it becomes 60 generic practices less.

• Terminology changes to support more consistent understanding and application. E.g:

• • “information items” replace “work products”, to describe the required result of a process. Today an output from activities in a specific process reside as information in a tool rather than a specific document or work product.
  • “verification” instead of “testing”, the previous “test specification” is now “verification measures”, to be valid for SYS/SWE/HWE
  • Removing “item” with “units” and “elements” to align with other standards

Concluding words

In summary the main changes are related to the plug-in concept with the addition of new process group and process areas.

But for companies with VDA scope, the main changes will be the detailed changes since they will not be affected by the removal/addition of process areas.
Out of the different detailed changes the “Strategy to CL2” and “added component test” are probably the main changes to consider.

In addition, there are change in the guidelines for how to conduct A-SPICE assessments. But this relevant for assessors is maybe a topic for afuture article.

Den 13de upplagan av SCSSS (Scandinavian Conferenc on System and Software Safety) kommer genomföras som workshop till den europeiska konferensen SafeComp som i år gästar Stockholm.

Viktiga datum

• 9/9 Workshops (bla SCSSS’25)
• 10-12/9 Safecomp huvudkonferens

SCSSS sedan 2013

The Scandinavian Conference on Systems and Software Safety (SCSSS) has become a central meeting place for Scandinavian safety experts from industry, public and academic organizations. Collaborating with other important relevant organizations, such as the Swedish Network for System Safety, SAFER and the Swedish Electromobility Centre, SCSSS has managed to gather roughly 100 participants, primarily safety engineers from industry, each year since 2013. The conference features presentations from industry and academia, with a strong emphasis on networking.

A lot of interesting research and development is currently ongoing in this field in order to create methods for process improvements, assessments and standardization of safety critical software and systems. With this conference, the organizers want to gather stakeholders for discussions and to create an inspiring environment for exchanging ideas and knowledge.

“The distribution between industry and academia is well balanced and help to inspire and network, which is the purpose of the conference”  says Even-André Karlsson, Addalot representative in the program committee.

Keynote speakers were Johan Hellsing from Heart Aerospace presenting the ES-30 aircraft with a unique Electric Hybrid Propulsion System (EHPS),

and Anton Nytén, Etteplan talking about safety challenges in the battery market.

In addition to the two keynotes there were a set of shorter presentations from various speakers. Below is a list of the different topics that were covered:

• Data-Driven Survival Modeling for Predictive Maintenance
• Ontology-based representation for assurance and compliance
• Holistic perspectives on safety of Automated Driving Systems
• Vehicle-Level Thermal Safety of Lithium-ion Batteries: Experimental Analysis and Method
• Case study: Automotive SPICE® extensions with functional safety at Volvo Group
• Quantitative fault tree analysis (qFTA) for autonomous systems,

In the evening there was a social dinner for more relaxed and informal time to nework.

The full program can be found at the conference web site and there you can also find all presentations to be downloaded.

In 2025 the conference will be in Stockholm, and we will shortly announce a call for presentations.

Manufacturers and importers that provide products with digital elements in the EU market will have to comply with the Cyber Resilience Act (CRA). This article contains some general practical advice on the implementation of requirements found in the CRA. Note that it is important for each company to make their own analysis and fulfillment of any regulation, including the CRA. This whitepaper is not a complete overview of the CRA and is not legal advice.

Affected products

The CRA applies to “products with digital elements whose intended, or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.” [Article 2.1], which is most any product that contains software. There are exceptions for products that are already regulated through existing legislation, such as in automotive and medicine. Open source projects are also exempted from complying to the CRA, but importantly this exception does not extend to the use of open source components in commercial products (see section on SBOM and open source below).

The CRA differentiates between critical and non-critical products, where critical products include products such as routers, microcontrollers, operating systems and industrial automation and control systems. Critical products are expected to be certified by a third party while non-critical products will be self-certified by manufacturers or importers.

CRA requirements

The requirements in the CRA include (but are not limited to):

• Secure development: The product must have been developed with security in mind, e.g. using a secure software development lifecycle (SSDL).
• Security testing: Apply regular security testing and security reviews of the product.
• Vulnerability management, including vulnerability disclosure and reporting of incidents.
• Security patches must be provided free of charge for the lifetime of the product.
• A Software bill of material (SBOM) must be provided with the product. The manufacturer is responsible for the whole product, including third party components and open source components that they include in their product.

Secure development

Secure development means that cybersecurity is considered in all phases of product development. This can be contrasted to trying to fix cybersecurity after the product has been developed, which will never be as effective or efficient. Products that are developed according to a secure software development lifecycle (SSDL) are said to be secure by design.

• Start with risk assessment and threat modeling, not with testing. It is often tempting to just test a product for vulnerabilities and fix those, but this will not fix the root cause of the vulnerabilities. Risk assessment and threat modeling is the foundation of secure development.
• Include security activities in the regular work. Security should not be a separate activity, but rather a part of normal development activities.
• Everybody should be involved in security. It can be tempting to hire someone to take care of security in product development, but this is not a scalable solution. Security needs to be everybody’s responsibility.
• Start small, improve and be efficient. It is not productive to do too much security work.
• Make sure that secure development activities are easily traceable for internal follow up, standards compliance or future audits.

Security testing and review

Security testing complements secure development by providing feedback and information on the security status of the product. There are many different types of security testing, where the most common include vulnerability testing and penetration testing. Security review includes re-evaluating previous risk assessments when appropriate.

• Security testing should start with people that are involved in the development of the product, even if they do not have detailed knowledge of security. Knowing the product and having access to internal documents makes it easier to identify possible security issues. Security testing should be a part of the existing testing and quality activities for the product.
• Penetration testing done by security experts can be useful, but should preferably be done once secure development practices are in place and should be used to complement, not replace, internal testing.
• Vulnerability testing is a broad topic, but using vulnerability scanners during development is a good starting point. Keeping track of vulnerabilities in third party components, such as open source packages, is a minimum.

Vulnerability management

Vulnerability management means continuously evaluating and managing vulnerabilities as they are discovered.

• Vulnerabilities in third party components need to be managed. Vulnerability testing can inform about the existence of such vulnerabilities, but there also needs to be a plan on how and when to patch those vulnerabilities.
• Externally reported vulnerabilities on a product must be handled by the manufacturer. Having a clear policy on how to respond to such vulnerabilities is a minimum.

Security patches

An essential part of any cybersecurity work is fixing discovered vulnerabilities together with continuous improvement. The CRA makes it mandatory to provide security patches in a timely fashion and free of charge.

• Having a regular release schedule is much easier in the long term than ad hoc response to new vulnerabilities. This can be a challenge for embedded products, but is a challenge that needs to be tackled.
• For products with dependencies to other products, it is important to handle interoperability questions. A security patch that cannot be installed due to interoperability issues is useless.

SBOM and open source

A software bill of material (SBOM) is essentially a “list of ingredients” for software. The reason this is important to provide, is that it provides transparency to possible risks and vulnerability through third party components. It is important to note that a provider of a product is responsible for that product, including third party components and open source components. This means that manufacturers need to apply cybersecurity practices not only on their own work, but also do due diligence on their supply chain.

• SBOM should be provided in a standard, commonly used, computer readable format. There are tools available that help with this. It is important to note that customers can and will use the SBOM to scan for risks and vulnerabilities.
• In addition to doing due diligence on open source licenses, manufacturers must also do due diligence on open source from a cybersecurity point of view.

CRA and standards

There is no specific standard that exactly matches the requirements in the CRA. However, the European Union Agency for Cybersecurity (ENISA) and the Joint Research Centre of the European Commission have published a report mapping standards to the CRA. The report contains a more complete list of requirements from CRA than is covered in this whitepaper and matches these requirements to different existing cybersecurity standards.

Cyber Resilience Act Requirements Standards Mapping – Joint Research Centre & ENISA Joint Analysis

In summary, the standards ETSI EN 303 645, ISO 27001 and IEC 62443 all have some overlap with the CRA, with ETSI EN 303 645 being the closest match. It is important to note that CRA is outcome driven rather than prescriptive and this is also the proper way to tackle cybersecurity. It is more important to understand what we are trying to achieve, than to implement something for the sole reason of compliance. This is also a strength of ETSI EN 303 645: “The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate and implement security solutions appropriate for their products.” (ETSI EN 303 645 V2.1.1 page 5). Even if a standard can provide assistance and guidance, it is always important to implement security that is appropriate for a product rather than blindly following a standard.

CRA and compliance

Companies that do not work with critical products will self-certify to the CRA. On one hand, there is a benefit of not having the cost of third party certification. On the other hand, the business risk of non-compliance still needs to be managed, as the fines are significant, up to EUR 15 000 000. Therefore it is reasonable to implement an internal audit and compliance control to manage the risk. However, traditional audits are often manual, which makes them costly, time consuming and only possible to execute occasionally. This is at odds with modern software development that emphasizes automation and agility when it comes to changes. A solution to this is to integrate the compliance controls into the development of the software, creating automatic controls of activities that are connected to CRA compliance. The human decisions of what solutions to implement for specific requirements are still needed, but the control that the implementation is still being followed can be automated and continuous, instantly detecting if some requirements are being violated. Compliance violations can happen e.g. if a certain test has not been executed, if an external web page has been moved or some feature is missing from the product. Continuous monitoring of compliance will make life easier both for business risk management as well as software development.

How we can help

Please contact us if you want help with understanding the CRA legislation, how it will affect your company and how you can integrate compliance into existing workflow. We provide workshops where your employees will get the chance to understand the challenges and provide solutions that work for your company and your products, as well as assistance and feedback on your journey towards CRA compliance.

The conference is organized by Addalot, KTH ICES and Swedish Electromobility Centre and has become the central meeting place for Scandinavian safety experts from different industries. It is an opportunity to share experiences and make new contacts. There will be an overview day followed by a day of parallel sessions with in-depth presentations and discussions about different challenges, techniques, standards and methods. We aim for a good mix of participants and presentations from different industries and researchers.

The conference program is now ready and registration is available.

This year we are proud to announce two keynotes:

The Emerging Battery Market – Navigating Safety Challenges

by Anton Nytén, Etteplan

As the global demand for energy storage solutions surges, the battery market is experiencing unprecedented growth. From electric vehicles to renewable energy storage, batteries play a pivotal role in shaping our sustainable future. However, this rapid expansion brings forth critical safety considerations that cannot be overlooked.

In this presentation, we delve into the dynamic landscape of the emerging battery market. We explore the latest advancements in lithium-ion, solid-state, and beyond. But beyond performance metrics and energy density, safety remains paramount. The talk will thus address the critical importance of robust safety protocols, from cell design to manufacturing and end-of-life management where topics such as thermal management, the impact of the regulatory framework and risk mitigation strategies will be discussed.

Innovations and safety implications of electrified aircraft

by Johan Hellsing, Heart Aerospace

Heart Aerospace mission is to decarbonize and democratize air travel. For this, we are developing the ES-30 aircraft and a unique Electric Hybrid Propulsion System (EHPS). The ES-30 will rely on batteries for shorter full-electric flights and will rely on turbine engines as energy reserve and for extended trips. The electric propulsion system introduces a new level of aerospace electrification in terms of installed power, and the hybrid propulsion system introduces a new level of system complexity. On top of this, every sub-system in the aircraft has to be designed to support full-electric aviation. The minimum level of system safety which will be required for an approved aircraft design is available in the EASA’s CS-25 Certification Specifications along with the EHPS Special Condition E-19. This keynote speech will cover some of the main aspects of how Heart Aerospace is planning to meet the aviation system safety standards, comparing EHPS to traditional solutions across the system and subsystem levels.

Geir was an entrepreneur out at the fingertips with the passion of seeing and realizing business opportunities. In 1989, after launching Q-Labs in Lund in southern Sweden he soon aimed for Q-Labs to go globally – and not many years later Q-Labs had offices in Germany and in the US.

Geir also had high interest to link industry with academia and “bridging the gap” was one of his slogans. As part of this strategy Q-Labs establieshed offices close to the strong software engineering universities and organizations such as Fraunhofer Institute in Kaiserslautern and the Universities of Lund and Maryland.

He also established cooperations with with some of the world’s at the time most prominent researchers (Harlan Mills, Victor Basili, Dieter Rombach, Bill Curtis and Claes Wohlin) and settled an “advisory board” for Q-Labs, where many of them had a seat. Furthermore, Geir managed for Q-Labs to get key roles in European Research Projects, e.g. REBOOT and PERFECT.

Geir was always on the outlook for new technology and opportunities, establishing co-operation with the founders of the technologies. This led Q-Labs to to introduce models such as Cleanroom Software Engineering and CMM to Ericsson and other customers.

After establishing a handful of offices globally, Geir wanted to keep the company together with his so called “One company approach”.  Many of us holds treasured memories of meetings with Geir joining in from different parts of the world…

Geir at the 25 years – ”open house” event, with new and old Q-Labs employees celebrated at Ideon Science Park in, Lund– where it all started.

After Q-Labs Geir engaged himself in:

• Establishing SEI (Software Engineering Institute) Europe, seated in Germany
• Establishing MARSEC a multimodal transport optimization company with focus on the maritime mode of transport employing the Industrial Internet of Things and Big Data Analytics technologies.

Geir enthusiasm was also present outside work. He became a passionate marathon runner and the last years he became an Eco-farmer at Malta, among other things producing olive oil.

Many people in the software engineering world and the software industry as such have many things to thank Geir for. Not only because of challenging work opportunities, advancements of software business but also for him showing what can be achieved through a what a can-do mentality.

Geir could personify a Whynotters (and drag the Yesbutters with him).

So please join us in honoring Geir – best by really conquer your dreams, as well in work as in life in general.