Alexander Poth
email: alexander.poth@volkswagen.de

Mario Kottke
email: mario.kottke@volkswagen.de

Andreas Riel
email: andreas.riel@grenoble-inp.fr

Scaling agile on large enterprise

published or not. The documents may come

Scaling agile on large enterprise level -systematic bundling and application of state of the art approaches for lasting agile transitions

I. INTRODUCTION

HE diversity of an enterprise's business areas demands individualized implementations of lean and agile. Often the main goal of the agile transition is to gain delivery speed. According to Albert Einstein: "Make everything as simple as possible, but not simpler", we have to find a way to achieve effectively the simple yet complete organizational setting. Furthermore, Conway's law [START_REF] Conway | How do Committees Invent?[END_REF] leads us to develop something customizable to build a lean and agile organization for a best fit to the specific products and services, which the organizational unit creates and delivers. These two aspects have to be handled to realize a lasting and sustainable transformation.

Large established enterprises are built around different business areas with independent business units or divisions in a matrix structure [START_REF] Gottlieb | The Matrix Organization Reloaded: Adventures in Team and Project Management[END_REF]. Most of these business units have the size of a medium-sized enterprise. Furthermore, large enterprises are mostly based on large delivery pipelines oriented on the efficiency paradigm of the Taylorism [START_REF] Taylor | The Principles of Scientific Management[END_REF]. Any transition aid for application within such context has to be able to handle this setting. More specifically during our first operational coaching of projects within the Volkswagen This work was not supported by any public organization or funding Group IT in past transformation initiatives we identified the following aspects an agile transition aid has to address: 1) Identify the target organization for the transition, including its boundaries.

2) Identify the organization's value stream, including interfaces at the boundary to "external" partners.

3) Define and clarify the transition's objectives. 4) Evaluate different approaches to lean and agile for their suitability in the particular organizational context. 5) Implement the selected approaches:

-Train people in the approach.

-Re-organize the workflows according to the approach.

-Align the new setting with the enterprise's governance and compliance structures. 6) Install cyclic checks for transparency and improvement:

-on a local view of the transition for "self-optimization"; -on a global enterprise view to develop the "setting";

-offer an open networking platform to reflect transitions.

7) Support scaling of transitions

This leads to the investigation question: How is it possible to address these demands with an easy to handle approach, which can be applied by a team of coaches in a structured fashion? Our objectives for achieving this are the following:

(O1) A transition kit is needed that is able to handle lean and agile approaches.

(O2) Based on the organization's stakeholders' current mindsets a specific set of methods and tools for the workflows has to be implemented.

(O3) The organization's specific product setting has to be taken into account appropriately.

II. RELATED WORK

This section investigates related published work with a focus on a holistic approach to addressing those. There is a huge amount of relevant approaches to organizational development [START_REF] Kesler | Leading organization design : how to make organization design decisions to drive the results you want[END_REF], alternative setups like holacracy [START_REF] Robertson | Holacracy : the new management system for a rapidly changing world[END_REF] or transitions [START_REF] Dikert | Challenges and success factors for large-scale agile transformations: A systematic literature review[END_REF] starting on grounded theories [START_REF] Gandomani | An empirically-developed framework for Agile transition and adoption: A Grounded Theory approach[END_REF] to practice collections of other enterprises [START_REF] Chen | Managing the transition to the new agile business and product development model: Lessons from Cisco Systems[END_REF]. We are interested in identifying well-known approaches, methods and tools that can be used as a kind of reference in various settings to reduce complexity. Our contribution is to bring together the team setting with its cultural and mental history thanks to an adequate set of approaches, methods and tools to realize a effective and sustainable transition. We structured related work according to this scope, rather than elaborating on all kinds of available methods and tools at the time of writing this article.

A. Setting Analysis

The Cynefin [START_REF] Kurtz | The new dynamics of strategy: Sensemaking in a complex and complicated world[END_REF] and the Stacey-matrix [START_REF] Stacey | Strategic Management and Organisational Dynamics[END_REF] are approaches to classify the product context into a complexity setting and the drivers of the transformation [START_REF] Rouse | A theory of enterprise transformation[END_REF]. This are useful approaches to identify the development context of the transitions product environment. The spiral dynamics model [START_REF] Beck | Spiral Dynamics: Mastering Values, Leadership, and Change[END_REF] and the Group Development Questionnaire (GDQ) [START_REF] Buzaglo | The Group Development Questionnaire: A Scientific Method Improving Work Team Effectiveness[END_REF] classifies the maturity of a group of humans who focusing together on an objective or purpose. As setup point on the teams maturity for transition approaches and methods this is crucial. Value-stream mapping [START_REF] Rother | Learning to See: value-stream mapping to create value and eliminate muda[END_REF] is an approach to optimize processes in a given setting especially for software [START_REF] Kersten | What Flows through a Software Value Stream?[END_REF] which come for the production [START_REF] Hines | The seven value stream mapping tools[END_REF] to the software development [START_REF] Poppendieck | Lean Software Development: An Agile Toolkit: An Agile Toolkit[END_REF].

B. Lean and Agile Approaches

Scrum [START_REF] Schwaber | Agile Project Management With Scrum[END_REF] and XP [START_REF] Beck | Embracing change with extreme programming[END_REF] are team approaches focusing on agile working. Kanban [START_REF] Ohno | Toyota Production -beyond large-scale production[END_REF] works in a team and in bigger organizations. SAFe [START_REF] Leffingwell | SAFe® 4.0 Reference Guide: Scaled Agile Framework® For Lean Software and Systems Engineering[END_REF], LeSS [10], Nexus [11] and Scrum@Scale [12] are approaches to handle the synchronization of more teams in a bigger organization. Furthermore a lot of variants are existing like Disciplined agile delivery (DAD [START_REF] Ambler | Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise[END_REF] or Agile modeling (AM) [49].

C. Methods and Tools

Design Thinking (DT) [START_REF] Liedtka | Designing for Growth: A Design Thinking Tool Kit For Managers[END_REF] is a method to develop an initial product in an iterative hypothesis based manner. Minimum Viable Product (MVP) [17] and derivations like Simple Lovable and Complete (SLC) [18] are tools to define an initial product version for delivery. Business Model Canvas (BMC) [19] or Lean Canvas [50] and its variants like for organizations internal communication [20] are used to identify the setting of a business to optimize in a later step the value-stream for product and its revenues. The Product Vison Board (PVB) [21] is used to for focusing a team on a product. INVEST [START_REF] Buglione | Improving the User Story Agile Technique Using the INVEST Criteria[END_REF] is used to systematically identify requirements for a product. Definition of Done (DoD) [START_REF] Davis | Driving Quality Improvement and Reducing Technical Debt with the Definition of Done[END_REF] or derivations like Levels of Done (LoD) are used to ensure that product versions fit quality definitions. To keep the delivery procedure lean and focused Product Quality Risk (PQR) [START_REF] Poth | Effective Quality Management: Value-and Risk-Based Software Quality Management[END_REF] mitigation can guide to the delivery.

D. Organizational culture and team psychology

The culture moves to a more internal lean start up [START_REF] Ries | The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses[END_REF] setting also in bigger enterprises. The objective of most digital business models [19] is scaling into the mass-markets [START_REF] Moore | Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers[END_REF]. Coaching approaches are reflected to be effective in the setting [START_REF] Ely | Evaluating leadership coaching: A review and integrated framework[END_REF] to address the agile teams.

E. Governance, Risk and Compliance

Governance has to establish standards like ISO 9000 for quality management, standards for risk management like the ISO 31000 and additional domain specific standards. Approaches for agile risk handling exists [START_REF] Shrivastava | A risk management framework for distributed agile projects[END_REF]. For service management, the ISO 20000 is an established anchor. Some concepts for agile governance [START_REF] Ambler | Scaling agile software development through lean governance[END_REF] and [START_REF] Talby | Governance of an agile software project[END_REF] exist, however their scope is limited to applying agile or lean principles outside a globally acting [START_REF] Bavani | Governance Patterns in Global Software Engineering: Best Practices and Lessons Learned[END_REF] enterprise context.

III. TRANSITION PROCESS

Within Volkswagen Group IT, we do not use one given method, model or tool because the organizations' s size demands context adequate approaches. More than 2000 internal employees and a lot of divisions and organizational units indicates the complexity which the transformation has to deal with. Therefore we decided to start with the basis: the team.

A transition kit and process has been developed and maintained by a central team, the Agile Center of Excellence (ACE), which guides and coaches agile transitions. ACE is a department within the Group IT uniting initial agile users from the first agile projects. The transition process consists of three phases: the transition itself, as well as a pre-and post-transition phase to ensure sustainable transitions. ACE supports transitions in the Group IT and other business areas of the Volkswagen AG based on their transition process and kit that has been enhanced over years.

The coaches establish the initial setup and alignment during the coaching phase of the team's external process expectations (figure 1). This is the initial link to process safety and compliance for the teams. The long-term alignment is checked by the project review. In the pre-transition phase, the "readiness check" is conducted to identify the status quo and objectives of the transition. The status quo identifies roles like sponsor of the transition, product/business owner and the team setting. Furthermore, agile artifacts like for the backlog and its items are investigated. Based on the evaluation of the acquired information, a transition can be recommend or not. In case of recommendation, the ACE can support the transition with the transition kit. In case of a non-recommendation to start a transition, the ACE will not support because there is low chance to finish the transition in time successfully. The biggest challenge during this phase is the interlocutor's honesty. All transition aspects are based on it and conveying information honestly and completely is needed to give the transition a chance to be successful. Therefore we decided that we start the transition with motivated and voluntary units supporting the transition and meeting the prerequisites from the outset.

The main purpose of the transition kit is to enable teams to deliver most product benefit within in a continuously changing environment. The ACE coaches help start agile projects and teach the team how to deal with impediments. Additional ACE tasks are:

-first aid in network, -promoting agile methods, -connecting committees, -supporting knowledge transfer, -combining agility practices of brands, -enable leadership to act in an agile way, -sensitize the unit to get an agile mindset, -pay attention to process safety. Every transition phase starts with a contract clarification to get a clear understanding of what will happen. Referring to the Agile Manifesto [39], the contract does not describe the HOW, but rather the WHAT. Depending on the results of the "readiness check" and the needs of a team, product or project, the transition duration will be estimated and a coaching package will be offered (cf. Section V). The contract defines the purpose, deliverables from both sides and the organizational issues like contractor and cost issues. The transition itself has four steps:

1. Preparation (evaluation of team and product setting) 2. Implement the methods and the tooling 3. Stabilization

Consulting

The preparation includes the execution of a kickoff workshop, consulting (project leads, development team) and agile workflow creation. Also includes support, moderation, preparation of the management and creation of Definition of Ready/Definition of Done and initial product backlog with the team. The initiation of the first meetings like refinement, planning, review and retrospective is a task, too. To implement the methods and the tooling the guide is always available for the team. The coaches train the team and the roles inside e.g. Scrum Master, Product Owner etc. to do the job to be done. The guide also moderates the necessary meetings like review, daily, retrospective, planning or refinement. Furthermore the guide assists the change management for motivation, conflict solving and workflow changes. The coaches are instantiating the initial setup and alignment of team external process expectations. This is the initial link to process safety and compliance for the teams. The long-term alignment is checked by the project review of the post-transition phase.

The stabilization step during the coaching (figure 1) is not so intensive for the coaches because the team should do their first steps alone. The coaches are always available for support and assistance, and in special cases will also assume the role of moderators. In this step, their job is to motivate, inspect, adapt and strengthen the change to be sustained. Solving conflicts is also part of it.

The consulting step is demand driven and mostly the end of the transition phase (figure 1). If the customer needs help, the coaches will help and give answers for questions to events, roles and workflow. The guides help the change management manage conflicts and adapt innovations.

The post-transition phase starts with a hold back (capability check in figure 1) of the transition team during the stabilization step and ends with a report. The report reflects the coaching contract objectives and also the agile issues and elements. Furthermore, the team or organization is registered as "agile". This flag will be used for the future agile governance checks (cf. Section VI) to ensure sustainability of the transition and incremental development of the people to stay up to date about the state of the art about agile.

IV. TRANSITION KIT

For the demand of the Volkswagen Group IT to transform classic project management to business agility we developed the transition kit. It contains the methods and tools which are released during the transition process. Within the transition process, we try to find the best choice of approaches, methods and tools to create value faster. The transition kit addresses the implement step of figure 1. The transition kit focusses on the key parts of figure 2. These key parts are the product or service which is the delivery to the customer, the team realizing and supporting the products, as well as the governance ensuring organizational standards. Governance can also be triggered by external demands for example from legislative changes. The transition kit has to support the setup of the demanded skills and capabilities of the team from the outcome view (product/service). Furthermore the governance has to handle the product or service risks by guiding the teams to be able to balance the business value and risks related to the product or services they handle. All three parts interact and need a holistic handling by the transition kit to realize a comprehensive product or service from the customer view who is using the product/service. The tool selection of the transition kit (table 1) is initially based on a first fit for purpose. This first fit was realized by a literature review [START_REF] Webster | Analyzing the past to prepare for the future: Writing a literature review[END_REF] to identify artifacts for the initial transition kit. The transition kit contains approaches, methods and tools which helps the coach and team to go in an effective way into the right direction during the transition. Over the life cycle the transition kit will be enhanced by adding and changing artifacts to better fit the current organizational culture, for an easier integration into the coaching or simpler use in a self-service approach for teams without coaches. The enhancement is triggered by feedbacks. While everybody can suggest new artifacts for the transition kit, the ACE will evaluate and integrate relevant suggestions during their cyclic inspections. The objective is not to have a maximum of possible elements in the transition kit, but rather to have a lean transition kit that can be trained easily and is effective in most organizational settings. To make it easy to find the right artifacts the transition kit is aligned with the product complexity, team maturity and the agile approaches.

To identify the projects the ACE supports with coaches we use the Stacey matrix. It is an easy to use way to identify if agile is helpful or not.

The assignment of tools to phases is based on experience during the supported transitions. The determination of the appropriate transition kit artifacts is done according to the following procedure: To start in a value-driven way, the initial focus of the transition is the product or service. The product is located on the Stacey-matrix. Over the product life-cycle, the complexity location is more or less stable in emerging marketswith a trend to reduction of complexity in mature markets or at the end of a product life-cycle. The current state is identified and the future result or objective will be considered to advance in the right direction. In a second step, the relevant governance guidelines are identified. Based on the product and governance demands, the current team skills and capabilities are focused on. The product team setting is located in the spiral dynamics model (table 2) color levels. This location is important because often organizations coined by Taylorism established over years, act on the "red level". These teams have to make their mindset leaner to achieve the "blue level". Agile teams typically act on levels of blue and higher. Each team has to grow level by level in their maturity. This leads to the adaptation of the used artifacts over the maturity journey of a team. Based on the team's maturity and their product environment complexity, the appropriate agile approach will be selected mostly based on the suggestions of table 2, however the guide and the team can make adjustments if they think another artifact would fit better. The artifacts help the team to progress in the transition, but most of the transition effort is to enable and coach the team to deliver a product. Some examples about the experience-based labeling of the table: Why is Kanban applicable in beige teams? Kanban does not define a set on rituals like retrospectives from Scrum which demands a minimum level of trust in the team to discuss issue frankly. Kanban itself is a more "mechanical" approach. Both approaches can be used to develop the teams to higher levels. With higher levels the teams are acting different within the same approach by discovering more opportunities with the higher team trust and openness. Why do we have small "item" like MVP and "big items" like Safe in the table? Depending on the context it is useful to start with small items to support individual transitions of teams. In case of a more top-down demand a big item reduces discussions about how to start because it is like a pre-defined "package" ready for rollout. This is also the reason why the transition kit does not add every approach, method or toolit selects some (first fit algorithm based) which work in the industrial context and tries to reduce redundancy were it is useful and possible by offering enough variance for the individual coaching of teams. The objective for the transition kit is to offer a practicable way for the transition of a team, without proposing any way possible.

The transition kit does not focus on finance procedures of the enterprise however some programs are using for example MVP based finance planning to manage their annual budgets in an agile fashion. However the approaches, methods and tools can be applied to special functions. For example, the Group IT security organization was an early adapter.

The transition kit is designed to develop culture, team maturity and products/services together. Of course it is possible to enforce some methods or tools on lower leveled teams, but the real opportunities are only realized within the right culture and team context. The application column in table 2 shows a current distribution of the application the line in teams.

V. COACHING ACE offers different volumes of coaching packages [START_REF] Poth | Effectivity and economical aspects for agile quality assurance in large enterprises[END_REF]. The package size is defined by the amount of time a team gets support from the transition team. The intensity depends on the time the guides (coaches) support the team. The coach sets up the team to address the demands and objectives of the transition by using the transition kit as guidance framework for the transition. The main focus of coaching is on the events, mindset, team performance, roles and their tasks, the used methods and how to inspect and adapt. Therefore the guide will use workshops with the whole team, as well as direct coaching.

Every coaching starts with a collection of information. This is necessary to find out what the transition (e.g. the project or team) really needs. To implement agility, the coach starts creating awareness of agile principles and values. With growing understanding, the flow will be created to support agile behavior. This means that the team can welcome and handle requirement changes having influence on the actors. The coach helps to give the team the power and knowledge they need. This is an ongoing process during all transition phases and may not be finished when the coach leaves the team.

When the transition goal is clear, the coach has to decide on which level to be most effective. If the transition has most effect on teams, the coach will focus on team members. The objective of the coach is to start small and establish the simplest possible set of artifacts from the transition kit to realize the objectives of the transition. For instance, if the coach decides implementing Scrum, he will support the Scrum team including the Scrum Master, the Product Owner and the development team. If the transition requires an organizational change, the coach will spend more time on management level where the responsibility for the portfolio is located. The tools and methods are all based on values and principles. The coach's main task is to make clear what the effects of their actual application are. Furthermore, the coach facilitates the teams with methods and tools for generic product and service development. An example is requirements elicitation and engineering with the product vision board to align the requirements at least with epics and stories oriented with INVEST and PQR (cf. table 1).

VI. GOVERNANCE

Each enterprise needs a governance structure ensuring that fundamental things are done in a deterministic way, and at minimum according to the state of the art. The state of the art is defined by organizational settings or derived from the market standard and regulations. Consequently, also all agile and lean teams have to establish and ensure the state of the art for their products and services. Depending on the product specific aspects, on top of the state of the art additional factors have to be ensured, e.g. market advantages. During the coaching phase aligned with the transition kit this is delivered by a team external coach. The coach has to make the teams sensitive for this governance topic and their team responsibility to stay aligned in the future. After the coaching phase the teams are independent and have to care about the "update" to the developing state of the art on their own. To make it easier for the teams, the governance offers update information about state of the art changes, which can be adopted by the teams. However, the governance has to ensure the alignment with the rail guards and update them to fit the state of the art. Rail guards are typically artifacts ensuring that some basics are done by the teams like for example an approval evidence for a deployment. Furthermore, the governance has to verify the effectiveness of its settings. These effectiveness checks are realized with controls. Different (domain) standards for System and Organization Controls (SOC) like [42] exist, but all have in common that the effectiveness of the established procedures has to be adequately checked, and if needed an alignment action has to be triggered. To ensure alignment with the settings and the agile and lean mindset a project review is established [START_REF] Poth | How to Assure Agile Method and Process Alignment in an Organization?[END_REF]. The project review (see figure 1) checks different aspects of an agile team or organization. Depending on the project or product classification (based on risk etc.) it will be checked in a deterministic way or randomized picked for a review. This ensures a basic transparency of alignment with the state of the art of the current portfolio.

The reviews are conducted by some coaches who have been trained in the evaluation aspects and their rating criteria. This common understanding about the aspects and rating ensures comparable results to derive organizational issues. Furthermore, an objective is not to change existing review aspects to keep the historical results in the dataanalysis pool.

The defined rail guards for the expected artifacts and outcomes for fulfilling external requirements like aspects of the GDPR [43] or quality standards like ISO 9000 are checked in the project review. The results are used on both levels, for the reviewed team as well as the overall organization. Most of the findings have to be addressed by the product teams, however some findings are seen in many teams. This is made by cyclic analysis of the project review results to identify "derivation pattern" which have to be addressed on the organizational level. A derivation pattern is identified if in a significant amount of the cyclic checks similar derivations are observed. This is the trigger to handle it not only on the specific product or service instance and start caring about it on a generic or organizational level. For each identified derivation pattern the governance checks why it does not fit to the product teams and their deliveries. This can lead to actions on the organizational level having a high bandwidth. Finally, there is the educational aspect that leads to inadequate settingthis is addressed by training or coaching offers to establish the things as intended. This may lead to refactoring the rail guards or artifacts to fit better into the project teams and the organizational culture. Figure 2 shows the relation between the product, the team and the governance. The relation "enhance" in figure 2 leads to the learning that as much as possible should be structured as self-service for the teams to reach higher autonomy and better scaling. This initial higher effort to develop the governance outcomes as self-service capability empowers the teams to live their self-organization and responsibility. To give feedback to the teams in a gamification context, the top ranked project review results are posted on an intranet page as a "champions league table" involving the entire organization.

The development and update of the transition kit is an additional important task to assure alignment with current regulations and the developing state of the art over the time. The transition kit has to support the governance artifacts like the rail guards during the team settlement. To do this, external and internal triggers are established. For example, the PQR method from the transition kit directly helps to make transparent why things are done in this way for some governance measures. An objective of the improvement of the transition kit from the governance perspective is to integrate as many measures as possible into the product or service artifacts or their direct production procedures. This integration makes it leaner and easier for the product teams to align their work with the expected outcomes and measures.

The Volkswagen Agile Community (AC) is the chance for everybody to get updates and the information about current development of agile and lean. It is an open community for networking and share knowledge about agile and lean. This includes also topics about the transition kit and agile governance.

DACH30 [41] is a trans-enterprise network to share experience about agile and lean. Trainings and skills are developed together. This ensures that the transition kit is reflected by external experts and is updated to the current insights of other enterprises.

The objective of the governance is to give the teams as much freedom for agility as possible while still demanding sufficient discipline from the teams to fit the compliance framework.

VII. EXPERIENCE REPORT

At Volkswagen AG Group IT, the transition kit development started in 2016 to support the coaches' daily work and has been enhanced continuously by the ACE and the coach guild to address the challenges of migrating to lean and agile methods in a structured way. Currently more than 100 product/service teams and organizational entities have been coached based on the elements of the transition kit. All those elements have been deployedsome more often than others (see table 1, column application). The teams are from the Group IT as well as other areas of the Volkswagen AG like plant production planning or vehicle development organizations, as well as smaller organizations like board member offices. The teams are supported during the transition in different life-cycle phases of their products and service. Some teams started on a green field, some were already established delivery teams. The range of software developed by the coached teams covers a wide rangefrom standardized ERP systems supporting human resources and production logistics to special software for supporting specific intellectual property of a business area. Also the architecture differs from established 3-tier architectures to cloud native micro-service based systems. The coaching phase differs in time from a few weeks to many monthsdepending on the size of the team or organization. Additionally, within the Volkswagen AG there exist a number of self-service based transitions which are often unknown to the ACE. By using the self-service, the teams have a low entry barrier because they can do it on their own way and speed, but the risk of applying inadequate elements of the transition kit is higher without an experienced coach.

The following parts of the case study reflect the objectives O1 to O3 and the observations of the application of the transition kit in the coaching phase as well as the results of the project reviews to have a long term perspective on the sustainability of the transition.

The lean and agile approaches are mapped to the transition kit artifacts to support the artifact selection. Depending on the approach, more or less options are offered to be chosen by the coaches and teams (O1). There is a trend in smaller teams without an end to end responsibility to use Kanban. This is motivated by the external process dependencies which limit the team's autonomy and freedom. The teams are often part of process driven value chains which drive the cycle time and delivery-dependencies. Hence, sprint commitments are not easy for the team. On the other side there is a trend to SAFe for transitions of multiteam organizations. Both show that the upper maturity levels are often not achieved.

The maturity derived from the spiral dynamics model of the teams is mapped to the transition kit artifacts to support especially lower leveled teams by choosing adequate approaches. With higher maturity levels the transition kit gets less importance because the teams have the capability of improving on their own and develop their appropriate way with supporting methods and tools to address their specific situation best (O2). Many teams have started their transition from the red or blue level Taylorism driven culture. However, some teams are built from scratch and in a greenfield area. Here, a quick move to "higher" levels is possible, because they do not have to learn to forget established habits and culture. The coaches typically can see some progress of one or two levels during their supporting phase. In the project reviews after a longer time a further progress can be observed. But in case of no strict application of agile methods and mindset some teams also go down to their "roots" with Taylorism habits. For these teams a "refreshing" coaching phase is suggested, if they still want to become agile.

The specific product setting with the complexity and value stream is supported by the transition kit, too. The artifacts are mostly generic and fit to the typical product settings in the complex setting (O3). In the future it could be possible to simplify the transition kit more by substituting complexity specific artifacts by generic ones.

The fact that the agile teams investigated in the case study are not permanently co-located does not significantly impact the application of the transition kit because most of the teams have some cyclic common physical meetings like refinements or retrospectives and use in-between communication tools to setup virtual team rooms.

The case study identifies that all phases of the transition are applied and supported as intended by the transition kit as described in section IV. The transition kit makes it easier to for new coaches to deliver transition support in a projectstyle to the teams in a standardized way. The integration of the transition kit in the holistic enterprise environment with a centralized product delivery process compliance helps the coaches and teams to be effective also from a compliance perspective. The controls of the effectiveness work because some transitions were not started because the environment did not fit according to the results of the readiness check. The control project review with its check aspects helps to show the effectiveness of the transition and its sustainability in the teams later on (see Fig. 3). Based on these measurements and metrics for agile projects, agile processes, and agile teams the governance identifies improvement potentials. For example, one related to the agile process ( IT-PEP agile which is the 2 nd bar in figure 3) effectiveness controls the re-thinking of the Group IT development process for a better alignment with agile and lean approaches and setting of guide lines which can easier integrated into operational excellence by the teams was indicated. Figure 4 shows the results of category IT-PEP agile of representative project reviews between 2017 and 2019. The x-axis are checked aspects of the project review which is aligned the teams agile adaption and the governance aspects. A more detailed description of the aspects and their grouping on the x-axis is in [START_REF] Poth | How to Assure Agile Method and Process Alignment in an Organization?[END_REF] described. The y-axis shows the fulfillment of the checked aspect. The bar in the middle shows the 2 nd and 3 rd quartile of values. The trend on derivations to the standardized templates of the development process is visible (every question has low values and almost all also high valuesespecially question f in figure 4). This derivation has led to the creation of a community of practice as a kind of working group whose mission is to enhance the Group IT development process to be better aligned with the state of the art habits of agile and lean working teams. This is one way of feedback to improve the environment to be more agile.

Often the coaches also identify new approaches, methods or tools which are evaluated as a kind of experiment during a selected team coaching. Results and lessons learned from this experiments are reflected in ACE to improve the transition kit. Furthermore, the case study shows that some transitions are not lasting or sustainable. The effectiveness of the transition is checked by the review with a delay to the coaching phase. By comparing the results achieved during the transition with the results of the progress reviews the progress or back-steps of the teams can be made transparent and thereby used for deriving the appropriate improvement actions. The selection of the reviews was made from feedback applications by randomized picking from the successful team transformation list and high-risk labeled projects/products. The highest frequency is one year for conducting reviews in a team. This is to avoid too many reviews in short time periods by random picking without the chance for the teams to improve in between reviews.

VIII. CONCLUSION

The presented holistic scaling approach demonstrates that a centralized agile governance can help large enterprises scale agile transitions in the product and service teams. This centralized ACEs coach guild and Agile Community are used to manage the agile knowledge and enhance the transition kit. The setup of a self-service driven team governance is a chance for establishing a lean governance approach. Furthermore the lean and agile mindset in governance offers the teams the chance to participate in the future "look and feel" of the governance, such as the development of higher automation of governance tasks and their evidences. This automation objective is a logical consequence of the automation with the everything as code approach [START_REF] Asthana | A Declarative Approach for Service Enablement on Hybrid Cloud Orchestration Engines[END_REF] of devops. The governance will check the effectiveness of the participation driven development with the controls like the governance initiated reviews to ensure that the enterprise enhance in a positive way aligned with the strategy. A second observation is that the governance develops fast if they live the lean and agile mindset themselves. Their responsibility is to serve the teams in an effective way to be compliant with external and internal requirements.

The evaluation about the effectiveness of coaching with a transition kit is seen on two points:

-At the end of the coaching phase on which the readiness check situation and the current outcomes of the capability check are compared. -At the project review with the distance view (at least 1 year) after the transition coaching. The objective of the ACE is to be effective by the coaching support. This is realized with the transition kit by applying and enhancing the transition kit continuously with the lessons learned from the transitions coaching. The efficiency is seen on the higher team transformation throughput of coaches. The issue is to have a generalized kit which is easy to instantiate in the specific team setting. This trade-off is a current enhancement focus of the transition kit. Furthermore a contribution is that this transition kit explicitly handles the mental team setting by application of the spiral dynamics model to apply adequate approaches and methods during the transformation to support effectivity the progress and sustainability also after the coaching phase.

IX. NEXT STEPS AND FUTURE WORK

Sustainability is a topic that needs more focus. Often the agile project review makes transparent that after the coached transition phase, the teams lose some of the leaned rituals etc. and fall back to pre-transition habits. We need to define or develop external triggers to reflect the team's rituals and progress in the developing of the agile and lean mindset without the coaches. This is a topic for an effective governance of the agile and lean processes.

Furthermore, the amount of skilled coaches does not scale with the demand. We need to enhance the transition kit to a complete self-service approach. Then teams with some "basic" skills can work more autonomously, needing less coaching. This is a governance and training issue. The training aspect is to enable the teams to do mostly everything in a self-service manner by offering a suitable transition kit. But on the other side the governance has to ensure that also self-service transitions have high quality outcomes.

Another open point is that the presented approach is only applied in a European enterprise culture. Its effectiveness in other cultural contexts still has to be investigated.

Next steps are the refactoring of the current process governance rail guards for a higher automation degree. The objective of the potential automation offers mature teams the integration into their automated product delivery pipeline (CI/CD chain). Some teams are currently experimenting and evaluating automated governance controls. The challenge is to find a balance between integrated standard tools and the freedom of the agile teams. Is automation an adequate indicator to determinate the product team maturity, especially in team's customized CI/CD chains? Will an individualized CI/CD chain slow down the integration of currently "independent" agile teams in future release trains of SAFe? Another interesting point is to extend the product based focus of the transition kit with a more lean and agile product finance scope like Beyond Budgeting [START_REF] Sirkiä | Adaptive Finance and Control: Combining Lean, Agile, and Beyond Budgeting for Financial and Organizational Flexibility[END_REF].

Fig. 1 :

 1 Fig. 1: Coaching to team autonomy with integrated compliance check

Fig. 2 :

 2 Fig. 2: Transition's key parts and their relationships

Fig. 3 :

 3 Fig. 3: Anonymized review results of the categories shows spreads and potentials (1 is most left bar -6 most right bar)

Fig. 4 :

 4 Fig. 4: Maturity of IT-PEP agile (1 is most left bar -6 most right bar)

TABLE I .

 I TRANSITION KIT ARTIFACTS AND THEIR MAPPING TO TRANSITION SPECIFIC KEY-ASPECTS

	Method/tool	Spiral dynamics team maturity	Stacey	Phase (average)	Application
	Retrospective	Purple or higher	All	pre, mid, post	High (over 75%)
	Design Thinking	Blue or higher	All	Pre	Low (under 25%)
	Minimum Viable Product (MVP)	Orange or higher	Complex & complicated	Pre	Mid (25% to 75%)
	Simple Lovable and Complete (SLC)	Blue or higher	Complex & complicated	Pre, mid	Low
	Business Model Canvas (BMC)	Purple or higher	Complex & complicated	Pre	Low
	Product Vison Board (PVB)	Purple or higher	Complex & complicated	Pre	Low
	INVEST	Purple or higher	Complex & complicated	Mid	Mid
	Definition of Ready (DoR)	Blue or higher	All	Pre, mid	Mid
	Definition of Done (DoD)	Blue or higher	All	Pre, mid	Mid
	Levels of Done (LoD)	Blue or higher	Complex & complicated	Mid	High
	Product Quality Risk (PQR)	Ref or higher	Complex & complicated	Mid	Low
	Scrum	Purple or higher	Complex & complicated	Pre, mid	Mid
	Extreme Programming	Green or higher	Complex & complicated	Pre, mid	High
	KANBAN	Beige or higher	Complex & complicated	Pre	Low
	SAFe	Red or higher	Complex & complicated	Pre, mid	Mid
	LeSS	Blue or higher	Complex & complicated	Pre, mid	Low
	Nexus	Orange or higher	Complex & complicated	Pre, mid	Low
	Scrum@Scale	Orange or higher	Complex & complicated	Pre, mid	Low

TABLE II .

 II MATURITY LEVELS OF THE SPIRAL DYNAMICS MODEL[START_REF] Beck | Spiral Dynamics: Mastering Values, Leadership, and Change[END_REF]

	Name	Structure	Motives	Characteristics
	Beige	Loose	Survival	Archaic, instinctive,
		bands		basic, automatic
	Purple	Tribes	Magic, Safety	Animistic, Tribalistic,
				Magical, Mystical
	Red	Empires	Power,	Egocentric,
			Dominance	Explorative,
				Impulsive, Rebellious
	Blue	Pyramidal	Order, right &	Absolutistic,
			wrong	Obedient, Purposeful,
				Authoritarian
	Orange	Delegative	Autonomy,	Materalistic,
			achievement	Strategic, Ambitious,
				Individualistic
	Green	Egalitarian	Approval,	Relativistic,
			Equality,	Personalistic,
			Community	Sensitive, Pluralistic
	Yellow	Interactive	Adaptability,	Systemic, Conceptual,
			Integration	Ecological, Flexible
	Tortoise	Global	Compassion,	Holistic, Global
			Harmony
	Orange or	Complex &	Pre, mid	Low
	higher	complicated
	Orange or	Complex &	Pre, mid	Low
	higher	complicated


Nic Volanschi
email: eugene.volanschi@inria.fr

Bernard Serpette
email: bernard.serpette@inria.fr

AllenRV: an Extensible Monitor for Multiple Complex Specifications with High Reactivity

Keywords: Online monitoring, Allen logic, Linear Time Logic

AllenRV is a tool for monitoring temporal specifications, designed for ensuring good scalability in terms of size and number of formulae, and high reactivity. Its features reflect this design goal. For ensuring scalability in the number of formulae, it can simultaneously monitor a set of formulae written in past and future, next-free LTL, with some metric extensions; their efficient simultaneous monitoring is supported by a let construct allowing to share computations between formulae. For ensuring scalability in the size of formulae, it allows defining new abstractions as user-defined operators, which take discrete time boolean signals as arguments, but also constant parameters such as delays. For ensuring high reactivity, its monitoring algorithm does not require clock tick events, unlike many other tools. This is achieved by recomputing output signals both upon input signals changes and upon internally generated timeout events relative to such changes. As a consequence, monitoring remains efficient on arbitrarily fine-grained time domains. AllenRV is implemented by extending the existing Allen language and compiler, initially targeting ubiquitous applications using binary sensors, with temporal logic operators and a comprehensive library of user-defined operators on top of them. The most complex of these operators, including a complete adaptation of Allen-logic relations as selection operators, are proven correct with respect to their defined semantics. Thus, AllenRV offers an open platform for cooperatively developing increasingly complex libraries of high level, general or domain-specific, temporal operators and abstractions, without compromising correctness.

Introduction

AllenRV is a monitoring tool for detecting temporal conditions about boolean signals over discrete time. Such boolean signals may directly originate from binary sensors, or be abstracted from non-binary sensors based on value thresholds. These signals typically correspond to the monitoring of cyber-physical systems such as smart homes, smart buildings, or other sensor deployments for IoT applications. It is assumed that input signals are piecewise constant, and are represented as timestamped values that are emitted upon significant value switches (for boolean sensors, this means any value switches). Timestamps are typically labeled in seconds or milliseconds. Based on the input signals and a set of specifications, AllenRV incrementally computes an output boolean signal for each specification. The output signal reports the satisfaction or violation of each monitored condition at each time point.

The AllenRV monitoring algorithm [START_REF] Volanschi | Implementing a semi-causal domainspecific language for context detection over binary sensors[END_REF] and its language for expressing temporal specifications [START_REF] Volanschi | A language for online state processing of binary sensors, applied to ambient assisted living[END_REF] are designed to satisfy several key requirements for monitoring applications in this domain:

-It supports the efficient monitoring of multiple specifications over a shared sensor infrastructure, by providing a 'let' construct for sharing common computations between different formulae. This avoids repeatedly computing the same sub-formulae many times. Monitoring multiple related specifications is a key need in applications that simultaneously monitor different aspects at different levels, such as low-level concerns (e.g. detecting basic interactions) and application-level concerns (e.g. detecting human activities), where higher-level aspects commonly reuse formulae of lower-level aspects. -It supports the efficient development of complex specifications by providing the possibility to define new user-defined operators on boolean signals, extending the comprehensive set of predefined operators. This allows to define programming abstractions that can be instantiated for different set of signals and which can also be parameterized with constant values such as delays or dates. The need for developing complex specifications is key when addressing real use cases, where programming abstractions are typically layered on top of each other. As a complement for the 'let' construct, addressing the reuse of common computations, a 'def' construct allows to reuse programming abstractions by instantiating them in different contexts. -It supports highly reactive applications that rely on the quick detection of conditions being satisfied or violated, by computing changes in the output signals even when they occur between two input events. In contrast, many of the available RV monitoring tools (e.g., [START_REF] Basin | Aerial: Almost event-rate independent algorithms for monitoring metric regular properties[END_REF][START_REF] Basin | The MonPoly monitoring tool[END_REF][START_REF] El-Hokayem | Bringing runtime verification home[END_REF]) only recompute output signals upon change events, and rely on the introduction of regular clock events for ensuring their reactivity; however, increasing the rate of regular clock events typically hampers efficient monitoring, and therefore is subject to a reactivity vs. efficiency tradeoff. AllenRV does not impose such a dilemma, thanks to the self-generation of timeout events relative to value changes, which trigger additional output signals recomputing, without waiting the next input event. The high reactivity requirement is key in many interactive or security-related applications.

While each individual feature is not necessarily novel, this combination of features ensures unprecedented scalability in terms of number and size of the monitored formulae and towards fine-grained reactivity.

For the specification of conditions on boolean signals, AllenRV uses a Nextfree subset of past/future LTL, with some metric extensions. This propositional temporal logic, equivalent to a subset of MTL [START_REF] Thati | Monitoring algorithms for metric temporal logic specifications[END_REF], has proven to be sufficient in practice for expressing various real services of ambient assisted living (AAL) in smart homes (SH), as pointed out in Section 3.

AllenRV is implemented by extending an existing tool for expressing context detection logic in ubiquitous applications called Allen [START_REF] Volanschi | A language for online state processing of binary sensors, applied to ambient assisted living[END_REF]. The original tool offered domain-specific operators on boolean signals, extensible with user-defined operators. Domain-specific operators included adaptations of the Allen-logic relations (during, overlaps, etc.) working on boolean signals, hence the name of the tool. AllenRV adds standard LTL operators Since and Until to the set of native operators, and adds a comprehensive library of system-defined operators, (1) re-implementing all the native operators, and (2) adding classical temporal operators such as bounded Historically/Once past operators. The correctness of the most complex operators, namely from the Allen logic, is ensured by formal proofs [START_REF] Volanschi | Scaling up RV-based activity detection[END_REF]. The AllenRV implementation is open-source software distributed under the GPL licence. 12 Tool Description

Foundations

AllenRV monitors temporal formulae over discrete time boolean signals, which are functions s : N → B. In practice, signals typically originate from binary sensors, and are given as a non-empty, possible infinite sequence of timestamped value changes s(t i ) i≥0 where t 0 = 0, and ∀i > 0, t i > t i-1 ∧ s(t i ) = ¬s(t i-1 ) (repeated values reported by the sensor are dropped). The current value of the signal on the interval [t i , t i+1 ) is s(t i ). Non-binary sensors can also be used as inputs by converting them to boolean signals using a command option that associates a sensor name to a threshold value.

A discrete time boolean signal can also be viewed as a set of states, that is, the discrete time intervals where its current value is 1:

{[t i , t i+1 ) ⊆ N | s(t i )}.
If the sequence of timestamped values from a sensor is finite s(t i ) 0≤i≤n , the last interval is [s(t n ), ∞). Note that, as the timestamps t i of a signal are strictly increasing, its states are non-empty, disjoint and non-adjacent.

A log is a sequence of timestamped value changes for a finite set of signals s ∈ S. The definition of signals over the infinite domain of natural numbers allows to use the standard LTL definitions of temporal operators on infinite traces. By putting Σ = 2 S , each log may be interpreted as an infinite trace in Σ ω , namely the infinite sequence (a t ) t∈N where a t = {s ∈ S | s(t)} is the set of signals whose current value at time t is 1. In particular, a finite log analyzed in offline mode is seen as its infinite constant continuation, that is, the last sensor values reported in the log are prolonged indefinitely.

Specifications

All operators in AllenRV take a fixed number of signals as input and produce a signal as output. Besides the boolean operators, having the expected pointwise semantics, there are 4 native operators in AllenRV, defined in Figure 1. Since and Until are the standard past/future LTL operators. Operator delay[T] is delaying a signal by a given period T ∈ N * , filling the beginning interval [0, T ) with 0.2 Thus, delay [START_REF] Basin | The MonPoly monitoring tool[END_REF] is equivalent to a classical Previous operator with a strong sense, i.e. false at t=0. Moreover, delay[T] is equivalent to the Once operator O [T,T ] in the MTL logic, when interpreted synchronously over the discrete domain of natural numbers, seen as timestamps [START_REF] Letier | Fluent temporal logic for discretetime event-based models[END_REF]. Finally, the >!! operator selects from a signal the states longer than a given duration T , but dropping their initial period of length T . This operator is similar to the Historically operator H ≤T in MTL, but has a strong sense, meaning that true >!! T is 0 on [0, T ), 3 while H ≤T true is 1 on [0, T ). Nevertheless, the MTL operator H ≤T can be expressed in terms of the Allen operator >!!, as will be shown in Section 2.3. In this sense, we may say that the logic implemented by AllenRV is a subset of MTL, containing unbounded past/future operators, the Previous operator but not the Next operator, and a subset of bounded past operators, including H [T,T ] and H ≤T (or, equivalently, O [T,T ] and O ≤T ).

since(p, q)(t) ↔ ∃t ≤ t . q(t ) ∧ ∀t ∈ (t , t] . p(t ) until(p, q)(t) ↔ ∃t ≥ t . q(t ) ∧ ∀t ∈ [t, t ) . p(t ) delay[T ](p) = {[t + T, t + T ) | [t, t ) ∈ p} p >!! T = {[t + T, t ) | [t, t ) ∈ p ∧ t -t > T }
Among these 4 operators, only delay[T] existed in the original Allen tool. The other three are extensions belonging to AllenRV.

The complete syntax of the specification language is given in Figure 2. A specification may start with a list of def constructs, introducing user-defined operators, and a list of global let constructs, introducing named expressions common to all the monitored formulae. After this optional prologue, comes the non-empty list of named monitored formulae, also called 'contexts'. The formulae may use boolean operators, duration operators such as >!! and its variations, and named operators, either defined in the system library or user-defined. Atomic formulae may be named expressions introduced via let or signals from the log referred by their name as a string. Constant delays and durations are by default in milliseconds, but can be also given in other units such as seconds or minutes. Expressions may also contain local let constructs, introducing named sub-expressions local to one formula.

User-defined operators are expanded as macros, by instantiating their definition with the given constant parameters and signal arguments. In contrast, the computation of each let expressions is shared by all the containing formulae. The global let construct is an extension belonging to AllenRV. Although it adds no expressiveness to the language, this extension allows to greatly improve performance when multiple formulae rely on common sub-formulae.

Prog -> Lib LetRules

Lib -> Def* Def -> "def" id ("[" id+(",") "]")? ("(" id*(",") ")")? "=" Context LetRules -> "let" id "=" Expr "in" LetRules | Rules Rules -> id ":" Context (";" Rules)? Context -> "let" id "=" Expr "in"

Context | Expr Expr -> Prod "|" Expr | Prod Prod -> Comp "&" Prod | Comp Comp -> Expr1 (">=!"|"<="|">="|">!"|">!!"|"<"|">") Int | Expr1 Expr1 -> true | false | "~" Expr1 | "(" Expr ")" | str
| id ("[" Int+(",") "]")? ("(" Expr*(",") ")")? Int -> id | int ("hr" | "min" | "sec")? Fig. 2. The syntax of the specification language for AllenRV.

The AllenRV Library

Based on the 4 native operators and leveraging the def construct, AllenRV offers a comprehensive library of more than 50 system-defined temporal operators, defined in the AllenRV language. Some of these operators came from needs experienced in practical applications in the SH and AAL domains, but should be useful in other domains, too. Other operators are well-known shorthands in temporal logics. Most, but not all of these operators existed in the original Allen tool, but they were implemented as native operators independently of each other, in ad-hoc ways.

Classic operators include the weak variants Z (weak Since) and W (weak Until), the unbounded past and future logic quantifiers O (Once), H (Historically), F (Finally), G (Globally), defined as expected using Since and Until, and also the bounded versions of past MTL operators H ≤T and O ≤T , defined in Figure 3 using the native operators. Other classical operators are the unary operators recognizing the raising edges of a signal (up), its falling edges (dn), or both (sw).

Operators derived from practice include:

different duration operators (<=, >), which are variants of the >!! native operator. They all select states from a signal, or sub-intervals thereof, by comparing them to a given duration T .

def occ(p,q) = since(q, p&q) # p has already occurred in this state of q def step[T] = delay[T](true) # step function, 0 on [0,T) and 1 afterwards def orig = ~step [START_REF] Basin | The MonPoly monitoring tool[END_REF] # true only at the origin of time, when t=0 def init(s) = occ(orig(), s) # selects the state of s starting at t=0 def selection binary operators derived from the 13 relations in the Allen logic. The Allen-logic relations define all the possible positions of two time interval with respect to each other: : during, contains, starts, started, ends, ended, overlaps, overlapped, meets, met, eq, before, after. For each interval relation IRJ, we implemented a binary operator r(p, q) on signals which selects all the states of p which are in relation R with some state of q. To improve the practical usefulness, the before and after have been interpreted as immediately before and immediately after, respectively. variants of the O (Once) and F (Finally) operators bounded by a signal, instead of a relative delay. This gives binary operators occ(p,q), meaning "p has occurred at least once in the current state of q", and possible(p,q), meaning "p is still possible in the current state of q". different forms of a binary flat(p,q) operator, which glue together the different states of p which occur during a same state of q. This operator is frequently used to reconstitute a whole period within a slot out of fragments of it: for instance, reconstituting a presence in a room out of sporadic movements while no other movements are sensed elsewhere.

other operators such as a binary operator far[T](p,q) selecting states of p that are far away (i.e. more than T away) from any state in q.

Online Monitoring

The online monitoring algorithm of Allen, first described in [START_REF] Volanschi | Implementing a semi-causal domainspecific language for context detection over binary sensors[END_REF], is based on detecting informative prefixes. The compiler constructs a graph for the set of monitored formulae, in which let-bound sub-expressions are shared by all the containing expressions, be it in the same or in different monitored formulae. The monitor pushes from bottom up the value changes for each formula from the corresponding signals; other events in the log are dropped. Evaluating certain kinds of operators may generate timer events that are merged in the event input stream. This way, output signals may change either triggered by input value changes or by delays relative to such changes. For example. the p >!! T operator schedules a timer event at time t + T when signal p raises to 1 at time t, and cancels the scheduled event when signal p falls to 0. If the timer event is encountered, this means that p has been continuously 1 on the interval [t, t + T ), so the output signal is switched to 1.

Future time operators are handled by computing three-valued output signals {0,1,?}, like in LTL3 monitoring [START_REF] Bauer | Runtime verification for LTL and TLTL[END_REF]. However, our monitoring, like any algorithm based on informative prefixes, does not guarantee that a definite signal (0 or 1) is computed the earliest possible for a monitored formula, but rather when sufficient evidence was gathered to evaluate it from bottom to top. However, it is important to note that, when computing an operator over the three-valued domain, our algorithm does not always block on unknown values. Indeed, some operators may return defined values (0 or 1) even when some of the inputs are unknown (equal to '?'). For instance, the value computed for a node since(p,q) is always 1 when the current value of q is 1, independently of the current value of p, and in particular even if p is currently unknown.

Another salient feature of our algorithm, already mentioned in the Introduction, is that the current output of any operator is recomputed both when the current value of its input changes (in the three-valued domain) and possibly on timer events, such as the timer events scheduled by the >!! operator mentioned above. An important consequence of this feature is that the monitor may signal the violation or satisfaction of a formula even when no event happens. For instance, when monitoring for a door left open more than time T during a Night slot using the formula during(Door >!! T, N ight), the satisfaction of the formula is signalled as soon as the delay T has elapsed since the door has been opened, without waiting for a new event to happen. In contrast, many existing monitors [START_REF] Basin | Aerial: Almost event-rate independent algorithms for monitoring metric regular properties[END_REF][START_REF] Basin | The MonPoly monitoring tool[END_REF][START_REF] El-Hokayem | Bringing runtime verification home[END_REF] wait for a next event, or rely on an artificial clock event to ensure reactivity. The problem in this case is that more the clock event is fine-grained, more the monitor is overloaded by processing these artificial events, decreasing its efficiency. For AllenRV, no such clock events are needed, and the monitor reacts as soon as it processes its timer events. In fact, our timer events may be considered as clock events generated on demand, without bloating the monitor with useless regular events. In practice, this strategy makes possible a reactivity of the order of 1 millisecond, currently unreachable by many other tools.

Input and Output

AllenRV is constituted by a compiler, called allenc and a virtual machine, called allen. The compiler takes a program adhering to the syntax in Figure 2, expressing a set of named formulae to be monitored, and produces a compiled module. The virtual machine is designed as a Unix 'filter', that is, takes a log on standard input (which may come from a file or a pipe) containing the value changes of input signals, and produces a log of value changes of the output signals -one for each named formula.

Both the input and output are in CSV format (colon-separated values): each line is a triple containing a timestamp, a signal name, and a value,. In the input log, signals commonly correspond to sensors, and timestamps are ordered in increasing order. Values having the same timestamp must correspond to different signals (recall that for each signal, the timestamps are strictly increasing) and are considered to happen simultaneously. Simultaneity is important in many Allen-logic operators such as meets(p,q), recognizing the situation when signal p falls at the same time when signal q is raising. In the output log, timestamps are not necessarily increasing, as output signals are de-correlated, and each value change is signalled immediately for maximal reactivity. This absence of sorting is similar to other recent monitors [START_REF] Basin | The MonPoly monitoring tool[END_REF][START_REF] Basin | Aerial: Almost event-rate independent algorithms for monitoring metric regular properties[END_REF].

Timestamps may be either opaque integers (number of seconds or milliseconds since "the Epoch") or human-readable standard date-time timestamps.

Command-Line Options

The allen command offers, among others, options for:

converting number-valued signals to boolean signals, by associating a threshold to a signal name (or a name pattern, to cover several signals) specifying symbolic values for a boolean signal (e.g., OPEN/CLOSED) corresponding to 1 and 0 debugging, e.g., by executing only one named formula in the specification, or by printing information about the computations performed at each event loading a library of operators extending the set of pre-defined operators This last option is used, for instance, to extend the set of 4 native operators with the AllenRV library.

Applications

AllenRV has been successfully used for processing logs of real homes produced by different smart home projects. First, it has been used to simultaneously monitor more than 50 real AAL services on logs spanning one year from more than 100 homes of seniors living along, produced by the HomeAssist project [START_REF] Consel | HomeAssist: An assisted living platform for aging in place based on an interdisciplinary approach[END_REF]. It has also been used to simultaneously monitor 27 real-size formulae on logs produced by the Orange4Home experiment [START_REF] Cumin | A dataset of routine daily activities in an instrumented home[END_REF], and to process logs of several weeks produced by the Amiqual4Home experiment [START_REF] Lago | The ContextAct@A4H real-life dataset of daily-living activities[END_REF]. All these examples are available with the AllenRV distribution, and can be reproduced easily by using the makefile in the examples subdirectory.

For instance, the Orange4Home example demonstrates on the corresponding dataset that AllenRV ensures close to real time processing with millisecond-class reactivity when processing the 27 AAL services simultaneously. These services include: infrastructure monitoring such as checking the correct functioning of light switches based on light sensors; recognizers for various activities in the home, such as showering, napping, or cooking; and meta-level rules built on top of the activity recognizers, such as alerting about unusual activity patterns, or about a potential danger when napping while cooking. The 'let' construct is especially useful in this context, when both activity and meta-activity rules are monitored. Without this construct, activity recognition formulae have to be computed many times, which, in this example, multiplies the total size of the monitored formulae by a factor of 4.3, and increases computation time by 63%.

Conclusion

Allen RV is a scalable and extensible tool for monitoring multiple complex specifications on discrete time boolean signals, scaling to arbitrarily fine-grain reactivity with no computation overhead. The system library demonstrates its smooth extensibility, but is only a starting point. The open platform constituted by the AllenRV opens the way to experiment with higher-level specifications abstractions in metric propositional temporal logic, driven by concrete practice. Although our previous practice was limited to the SH and AAL domains, we hope that this platform will be useful in other sensor-based applications in the IoT realm, for example.

Fig. 1 .

 1 Fig. 1. The native operators in AllenRV.

Fig. 3 .

 3 Fig. 3. Defining the bounded past operators O ≤T and H ≤T in AllenRV.

https://github.com/NicVolanschi/Allen

From its definition, the first state of delay[T] cannot start sooner that time 0+T.