Faïda Mhenni
email: faida.mhenni@supmeca.fr

Jean-Yves Choley

Franc ¸oise Caron
email: francoise.caron@eiris.fr

Antoine Munck
email: antoine.munck@dps-fr.com

Collaborative Mechatronic Design and Systems Engineering: an Educational Experiment with KARREN

Designing mechatronic systems implies collaborative work with shared parameters between contributors from different domains. Moreover, each domain needs to capitalize knowledge (e.g. design rules) in order not to reinvent specific calculation or simulation processes. In this paper, it is explained how students have been implied in a collaborative design project dealing with an aeronautic actuator, namely an EMA (Electro-Mechanical Actuator) for aileron actuation. Comparing three candidate kinematic architectures regarding the initial set of requirements, the project articulates modeling and simulation with Modelica language, the selection of relevant COTS components and their integration into a 3D mock-up within a wing and aileron assembly. In order to share relevant system and components parameters between design activities, KARREN tool is evaluated and configured for this project thanks to a preliminary systems engineering study to minimize the number of needed iterations to eventually converge on appropriate architectural solutions and their evaluation and comparison.

I. INTRODUCTION

The fast-pace technological development enabled man-made systems to be smarter, more powerful and integrate more functionality for the end user. This led to multi-disciplinary systems integrating components from different domains such as sensors, electro-mechanical actuators, control and power electronics, in order to satisfy a set of customer requirements. They may be mechatronic systems, Cyber-Physical Systems (CPS) or even Cyber-Physical Systems of Systems (CPSoS) as defined by the CPSoS European project 1 .

For such complex highly integrated or/and distributed systems, systems engineering approach supports design teams to elaborate a consistent set of requirements and synthesize functional and components candidate architectures that must then be evaluated and compared with respect to a set of requirements (such as performance, cost, mass, efficiency, etc.). The evaluation of the different architectures requires various competencies and thus involves different teams and domainspecific models (such as mechanics, electronics, computer sciences, safety, etc. ) with specific objectives (optimize the performance, reduce costs, reduce safety risks, etc.). In order to organize the system design, systems engineers provide a global system view that enables to identify the different engineering domains required and their interactions.

For highly integrated systems, the collaborators from different domains cannot work separately as they are interdependent and deal with some common parameters. The interdependencies come from "shared resource (e.g. weight, cost) limits, geometric fit, spatial separation requirements, I/O interface conventions, timing constraints etc" [START_REF] Klein | A complex systems perspective on collaborative design[END_REF].

This requires an efficient sharing and synchronization of the common parameters between the different teams. Moreover, there is a need to provide each collaborator with a personalized framework by giving him access to the appropriate set of requirements and parameters regarding his area of expertise.

To cope with this problem, two approaches can be considered. The first one is to use a fully integrated unique tool that covers (supports) the whole design process from requirements definition to the final solution. However, no such universal tool exists yet that integrates all involved domains. Moreover, it is not strategically wise for industrialists to depend from a unique tool editor. In addition, this approach is constraining for industrialists that have their preferred and own developed domain specific tools.

The second approach is to rely on different domain specific tools. The challenge for this approach is to enable the different teams to collaborate efficiently and to compare and synchronize the design parameters. The work presented in this paper relies on a KBE (Knowledge-Based Engineering) tool, in order to share requirements and parameters between different domains designers and to perform trade-offs. Systems engineering is used to distinguish domain-specific data (knowledge and parameters) and the inter-domain data that should be shared in order to have an effective data sharing and to ensure the consistency between domains.

Three student teams are involved in an educational project to design an Electromechanical actuator (EMA). Each team is considered as a domain specific team and is in charge of a particular task. Parameter exchanges among the teams, that used to be done via e-mail or direct conversations in the previous sessions of this teaching module, are now performed via the collaborative KBE tool used. Prior to students work, teacher play the role of systems engineering team and provide the students with the global system view as well as the requirements that are shared via the collaboration platform.

This paper is organized as follows. First, an overview of the related work is given in section II. In section III, Knowledge-Based Engineering tool KARREN is presented. Section IV explains how to organize the collaborative work with KARREN, having a Systems Engineering approach. The proposed approach is then applied to a case study in section V with an educational experiment. The paper is finally concluded in section VI.

II. RELATED WORKS

Todays' systems are of increasing complexity with shorter time-to-market and increasing distance between industrial partners [START_REF]The Changing Landscape of Enterprise ICT-Responding to New Possibilities and User Demands[END_REF]. The traditional sequential design where the system is split into different domains, each domain performing independently from the others is no longer suitable. Indeed, it is time consuming and very costly as it requires many iterations implying a lot of work to be performed several times when domains do not agree on the values of shared parameters. Instead, collaborative design allows to reduce both cost and time provided that there is a good management of shared parameters to perform trade-offs in order to synchronize their values.

The data exchange between domains can be performed with traditional means such as e-mails, but more reliable techniques are compulsory for efficient collaborative design. For this purpose, many attempts to support collaboration between different design teams have been achieved.

Collaborative work can rely on PLM (Product Life-cycle Management) including a PDM (Product Data Management). PLM is a specific information system that gathers the various data and processes related to the product to be designed and its life cycle, allowing the various involved professionals to share this information within collaborative environments [START_REF] Segonds | Proposition of a plm tool to support textile design: A case study applied to the definition of the early stages of design requirements[END_REF]. However, PLM does not allow an easy access to parameters and rules that are embedded in models.

In [START_REF] Eynard | Collaborative and remote design of mechatronic products[END_REF], a web-based CSCW (Computer Supported Collaborative Work) tool is used on a remote and multi-site educational design project of a mechatronic system, for the management of the project and data sharing, with mixed results. As a conclusion of the experiment, it is pointed out that the availability of initial information to be shared by all design teams is important. The possibility to have face-to-face meeting is also mentioned as being necessary.

PIDO (Process Integration and Design Optimization) tools, such as Model Center and Isight , also enable the integration of different domains tools, with the automation of an optimization cycle that allows tools to share parameters. For a better management of the optimization process, an agent-based approach for partitioning and coordinating the collaborative design optimization of complex systems is proposed [START_REF] Guizani | Agent-based approach for collaborative distributed mechatronic design[END_REF]. However, these tools are not relevant for complex design processes implying many domains and diverse collaborating companies with their specific knowledge and design processes and tools, with some modeling that must not be shared for intellectual property reasons or that are not available at the same time. Moreover, these tools are dedicated to the optimization of a single given architecture for a system to be designed, but not to share parameters in order to facilitate trade-offs to choose the best architecture among several ones. KBE (Knowledge-Based Engineering) tools [START_REF] Monticolo | A metamodel for knowledge configuration management to support collaborative engineering[END_REF] are preferred for collaborative design, especially in the early steps of a project, since they deal with knowledge, namely design rules and system parameters rather than modeling files. Beyond collaborative design and the necessity of sharing parameters, they allow capitalization and re-use of knowledge, which is of great value for industrialists.

KARREN (Knowledge Acquisition and Reuse for Robust Engineering) from DPS (Digital Product Simulation) French company, is one of these tools and is used in the present educational work, in relation with a French research project (MIMe). This tool will be presented in the next section.

III. INTRODUCTION TO KARREN KARREN (Knowledge Acquisition and Reuse for Robust

Engineering) is a KBE (Knowledge-Based Engineering) and Model-Based software framework that enables collaborative engineering across all product development cycles bridging multiple disciplines and organizations. KARREN lets users mutually share and reuse best-practice knowledge and provides consistent parameters for their processes, tools and models. Employing KARREN enables real-time collaboration for making better and timelier design decisions even in a multibusiness, multi-disciplinary and multi-actors environment.

KARREN functionalities rely on its ability to capture physical related product behavior data, information and context for efficient and effective reuse of knowledge. This tool does not focus on the CAD models or simulation results, but rather targets common parameters and rules across multiple behavior simulation and design stages from concept to completion in a centralized database of knowledges.

KARREN is based on a set of concepts as showed in Fig. 1. The main concept is ICE (Information Core Entities): a structured and generic entity of engineering knowledge. An ICE is the smallest entity to be manipulated. Users decide the most appropriate ICE granularity level. Two crucial types of data can be saved: parameters (may be geometric, physical, material, directory shared) and rules (may be business, logical, boundary conditions, mathematical relations, tables of discrete values, etc.).

A system can be described through different viewpoints at various abstraction levels (models) all along its complete lifecycle. A relevant interaction between these models will enable system complexity management and optimization. Viewpoints are captured in KARREN as User Configurations (UCs) and are composed of ICEs. Whereas needed interfaces between views within a collaboration are stored and managed as Knowledge Configurations (KCs) (Fig. 1).

To enable the parameters exchange/synchronization between KARREN and existing tools (such Excel, Dymola, Catia, etc.), some connectors are available.

KARREN concepts are initially based on the PhD research work of Julien Badin [START_REF] Badin | Ingénierie hautement productive et collaborative à base de connaissances métier : vers une mthodologie et un méta-modèle de gestion des connaissances en configurations[END_REF] and former French research project ADN [START_REF] Monticolo | A metamodel for knowledge configuration management to support collaborative engineering[END_REF], [START_REF] Badin | Ingénierie hautement productive et collaborative à base de connaissances métier : vers une mthodologie et un méta-modèle de gestion des connaissances en configurations[END_REF]. KARREN is now being enhanced within the French research project MIMe.

For this, several collaborative case studies are performed within the project to provide appropriate feedback. In addition, the tool is tested in an educational framework in a design project teaching module at SUPMECA.

IV. PROPOSED APPROACH FOR COLLABORATIVE WORK

WITH SE AND KARREN This section presents the proposed approach to enhance the collaborative work with KARREN. The first step is to capture the system requirements. We assume that the requirements have already been defined by the systems engineering team with an appropriate methodology [START_REF] Mhenni | SysML-based methodology for mechatronic systems architectural design[END_REF]. The system requirements (captured in the system SysML model or any other requirements modeling tool) are translated into requirements ICEs (ReqICE) in KARREN. The second step deals with functional and candidate components architectures definition. This part is also performed by the SE team using SysML or any other SE modeling language.

On this basis, ICEs can be defined in order to identify shared parameters of the system by different design teams. The choice of the way how ICEs are built (partitioned) is up to the SE team and depends on the partition of the domain teams that will perform the different simulations.

The most obvious way is to create an ICE for each component, especially when we are at a high level of detail and the number of shared parameters is not excessively important. If the number of parameters is important or if for the same component different teams enter into play, then, several ICEs can be created for the same component, for instance with separated multiphysical domains. In the specific case of a DC motor, a unique ICE may be defined, encompassing electromechanical, electrical and 3D parameters. But a more accurate cutting may lead to a more efficient collaborative work, by providing each team with exactly the needed parameters. In this case, for the DC motor, there may be different ICEs for the electrical, electromechanical, 3D aspects respectively. These ICEs may be created in the project Workspace or imported from the Knowledge Information Database that is used to store the enterprise knowledge (Fig. 1) if they already exist. In the first case, they are also automatically stored in the database of the Knowledge Information Database and may be used in different other projects. Each domain team performs the required simulations in their domain specific tools and have to synchronize the shared parameters via KARREN. To facilitate this tasks, some connectors exist to automatically perform the parameters synchronization (for instance there is a connector for Dymola and Catia). Once the teams have final results of their simulations that satisfy the requirements, they publish their ICEs so that they become visible to all the other users to perform trade-offs.

V. CASE STUDY

A. Case Study Presentation

The case-study considered in this work is an Electro-Mechanical Actuator (EMA) for a general aviation small aircraft. The EMA is intended to actuate the aileron of the aircraft, replacing the existing rod, cables and lever mechanism (Fig. 3), while minimizing changes that may be done to the wing and the aileron structures.

The academic project is then presented as follows: 36 master students of SUPMECA (France), organized into 12 design teams (four teams A, four teams B and four teams C), are provided with a set of system requirements, a description of three candidate architectures to be compared with regards to the requirements and a 3D mock-up of the wing and aileron. They are asked to fulfill three tasks. The first task is to model and simulate a kinematic architectures with Modelica language [START_REF]Modelica A Unified Object-Oriented Language for Systems Modeling[END_REF] (using Dymola or OMEdit tools) to dimension the different Fig. 3. The existing lever, rod and cables control mechanism components in order to satisfy the requirements. The second tasks consists in finding COTS components with the properties determined by the simulation. Finally, the last tasks consists in building the 3D-mock-up of the components and insert them into the provided mock-up to check whether they fit into the allocated space in the mock-up.

The students here are considered as domain teams and the teachers play the role of the SE team. Prior to the intervention of the different domain teams, the SE team has followed a SE approach (c.f. [START_REF] Mhenni | SysML-based methodology for mechatronic systems architectural design[END_REF]) to define and analyze the system requirements, identify a functional architecture and propose three candidate component architectures.

The initial requirements for this case study are given in Fig. • Direct drive architecture, with a motor and a gearbox that are inserted on the rotating axis of the aileron and directly • 4 bars architecture, with a rod and crank mechanism actuated with a motorization fitted in the wing. The SysML Internal Block Diagram (IBD) for this solution is given in Fig. 8. To study the different architectures, the students are divided into three teams each having a specific task:

• Team A has in charge to build a Modelica model and to simulate it in order to quantify the required parameters of the different components, while complying with the performance requirements;

• Team B has in charge to find existing off-the-shelf components (COTS components) conforming with the simulation results among available supplier components, or to give the definition of new specific components to be designed for the system (e.g. rod and crank);

• Team C has in charge the 3D integration of the whole mechanism in the wing and aileron assembly, while minimizing structural changes and aerodynamic effects due to added devices; An iterative collaborative design process (Fig 9) implying all three teams has to be performed in order to simultaneously take into account performance, 3D integration and "COTS mostly" requirements, thus allowing necessary trade-offs to cope with all these constraints for the three candidate architectures.

The use of KARREN helps in sharing parameters and minimizing the number of iterations with more effective tradeoffs. These iterations and trade-offs are mainly due to the following situations:

• When team B chooses a set of actual components (COTS and custom ones) in conformance with the given calculated parameters from team A, team A has to check whether the actual components (COTS and custom ones) parameters values still fulfill performances requirements by taking them into account in the simulation models. If not, a new iteration has to be performed, with potential • When team C integrates the actual chosen components provided by team B in the wing and aileron assembly, a fitting problem may occur, due to 3D constraints such as collision, protuberance that may not be appropriate for some aerodynamic reasons, or unacceptable major requested modifications to the wing or the aileron structures. If so, team B is asked to choose new actual COTS or custom components, and as a consequence, to ask to team A whether expected performances are still achieved;

• Obviously, some iterations and trade-offs are also needed When the initial requirements are modified during the project, even slightly, whatever the reason; The project manager (the teachers together with DPS team for this project) has to create the different configurations in KARREN as well as the different ICEs if they have not been created yet and give access rights to the appropriate teams. In this project, we have considered to create one ICE per component (as given in the IBDs above excluding the kinematic joints and the housing) for each architecture. Each component ICE is composed of a list of parameters that are shared among the different teams in the collaborative design process and may also include one or more rules on these parameters. For instance for a motor, nominal torque, speed, current and voltage as well as torque constant, resistance and inductance. Based on this set of ICEs, some User configuration have been created for each domain (Dymola modeling and simulation, components selection, 3D integration), this for each students' team. The Project Workspace with the knowledge configuration containing all the ICEs and the different User configurations for each architecture are given in Fig 10.

B. Results and Discussion

In this sections, some results of the students work will be presented.

The modelica model for the 3-bars architecture is given in Fig. 11. This model contains a motor, a gearbox, a set of components to model the ball screw nut, the wing, the aileron together with some kinematic joints, sensors etc. Fig. 12 shows some simulation results and we can see for instance (see the blue curve) that the EMA reached the upper position The ICEs parameters being mapped with the corresponding Modelica model ones thanks to the connector, after each simulation, parameters in KARREN are synchronized with those of Modelica. Once the simulation results are satisfactory (i.e. the chosen components parameters satisfy the system requirements), Team A must publish their ICEs so that they become visible to other teams.

Based on Dymola results, Team B has to choose COTS from existing suppliers. For instance, for the 3 bars architecture, the brushless motor and gearbox in Fig. 13 are chosen. During this work, some feedbacks about this collaborative design experiment have been given by the students and professors, such as:

• The set of available parameters in ICEs should have been strictly restricted to shared parameters. Indeed, the preliminary work to define ICEs is based on the SysML system modeling and has to be more precise;

• An Excel COTS components database would have been valuable since a KARREN-Excel connector is also available. If this database contains components costs, it is then • As stated in [START_REF] Eynard | Collaborative and remote design of mechatronic products[END_REF], face-to-face meetings were needed to help organizing the collaboration and for important project reviews. Obviously, KARREN (and collaborative tools in general) is not intended to replace some important project coordination meetings.

This experiment provided KARREN developers and engineers with users' feedback in order to enhance this collaborative design tool, while also giving means to better implement the collaborative design methodology within MIMe research project.

VI. CONCLUSION

This educational experiment deals with different tools such as Dymola (Modelica) and CATIA, in order to design an Electro-Mechanical Actuator in a collaborative work context. KARREN tool and specific connectors are used to allow sharing parameters between design teams and to perform trade-offs to fulfill performances and integration requirements. Three candidate architectures for this small aircraft aileron actuation system are designed at the same time to be compared. KARREN proves to be helpful to support collaborative work as it shortens design iterations and allows trade-offs on components parameters to converge towards acceptable solutions with respect to the given requirements. This experiment is also valuable since it provides the students with the opportunity to become familiar with collaborative design in a context that tries to imitate industrial design projects in mechatronics.

Fig. 1 .

 1 Fig. 1. Conceptual architecture of KARREN. Source DPS

Fig. 2 .

 2 Fig. 2. Configurations in KARREN. Source DPS

4

 4

Fig. 4 .

 4 Fig. 4. The Initial Requirements

Fig. 5 .

 5 Fig. 5. The three different architectures to be compared

Fig. 6 .

 6 Fig. 6. Component architecture for direct drive solution

Fig. 7 .Fig. 8 .

 78 Fig. 7. Component architecture for 3 bars kinematic solution

Fig. 9 .

 9 Fig. 9. The iterative design process

Fig. 10

 10 Fig. 10. KARREN Workspace

Fig. 11 .

 11 Fig. 11. Dymola modeling of the 3 bars architecture

Fig. 12 .

 12 Fig. 12. Dymola results for -30 to + 30 angular displacement

Fig. 14 .

 14 Fig. 14. 3D integration with CATIA, upper surface view

http://www.cpsos.eu

ACKNOWLEDGMENT

The authors would like to thank the MIMe project consortium with its industrial and academic partners, with more particular thanks to French SMEs DPS (Digital Product Simulation) and EIRIS Conseil. MIMe project aims at enabling structured collaboration for mechatronic system design. The project involves academics and industrials: Digital Product Simulation (DPS), PSA, Valeo, Deltacad, Soyatec, EIRIS Conseil, UTC, SUPMECA and Estaca. The main goal of the project is the development of a collaborative platform to assist engineers during their collaborative design process and enable sharing parameters and constraints of different models and disciplines by means of Knowledge Based Engineering. The project started on 01/10/2015 for a 3 years duration and is mainly founded by the French state and Ile-de-France Region.


Poppe

S Mattalia
email: sophie.mattalia@idele.fr

M Rocland

S Aguerre

M Poppe

Test-day genetic evaluations: a tool to measure herd resilience through monthly milk records

Test-day genetic evaluations: a tool to measure herd resilience through monthly milk records

Introduction

Cows are said to be resilient when they are able to maintain their performances throughout environmental disturbances or recover quickly if they are affected. Management practices can have an impact on these disturbances and the cows resilience. Poppe et al. (2019Poppe et al. ( , 2020) ) showed that the variability of fluctuations around the expected lactation curve, measured through the natural logarithm of the variance of the deviation between the observed and the expected daily milk yields (LnVar) was a promising proxy to measure resilience at the cow and herd levels. However, these studies were based on daily records obtained by automatic milking systems, which limits the potential use of this indicator in commercial farms. In France, expected lactations are provided by Institut de l'Elevage twice a year to the Milk Recording Organizations (MROs), in order to predict the production of each herd. Predictions use the genetic and environmental effects estimated from a genetic evaluation based on a testday model. These effects can also be used to construct the expected lactation curve of the cows with past records and knowing their own parameters (year, age and season of calving). In this study, a herd resilience indicator (LnVar) was estimated for each French Holstein herd using monthly test-day records. The objective was to assess to which extent the conclusions of Poppe's study were still valuable with less regular records, and whether a genetic evaluation could provide information to produce new herd management tools related to resilience.

Materials & Methods

Description of the genetic evaluation.

A genetic evaluation of Holstein cows was performed in October 2019 on milk yield, based on a test-day model described in Leclerc et al. (2008Leclerc et al. ( , 2009)). This evaluation used all test-day records collected by MROs on Holstein cows in lactations 1 to 3 and having started their first lactation since September 1 st , 1989 (more than 14 Mo cows). A random regression test-day model in which the first 3 lactations were considered as correlated traits was applied. In addition to a herd-test-day effect, the shape of the lactation curve defined by parity-region was taken into account, cumulating cubic splines of each level of the effects of calving month, calving age, length of dry period and gestation. Genetic and permanent effects were included using a reduced rank model. Days in milk, region-year-parity and herd-year were used to model the residual variance.

Selection of cows and herd-years. We selected test-day records of French Holstein cows in first parity and included in the genetic evaluation. The lactations should have started between September 1 st , 2014 and August 31 st , 2018 and have at least 2 test-days. Cows should have performed their lactation in one single herd. Only performances observed before 350 days in milk (DIM) were considered and were assigned to a given year corresponding to the calving year (Year n from September n-1 to August n). Selected herd-years should have recording intervals of less than 5 weeks and at least 10 cows in first lactation. 35,719 herds-years met all requirements, corresponding to 711,485 cows (on average 19.9 +/-10 cows per herd-year). Each cow had on average 10.3 +/-1.4 test-day records.

Estimation of LnVar.

For each herd-year, LnVar was estimated as follows: first, for a given cow j in herd i and with a performance recorded during the test-day k, the expected milk yield was estimated by the sum of all estimated effects affecting the cow at this test-day. Then the deviation δijk was estimated between the observed and the estimated milk yields. The variance of these deviations was used to estimate the individual fluctuation of the lactation curve around its expectation. It was log-transformed in order to be normally distributed: LnVarij = Ln (Var(δij)) Lastly, the indicator LnVar of the herd-year i was estimated as the mean of the individual fluctuations LnVarij of the cows with test-day records in this herd-year.

Herd-year descriptors. Several descriptors were computed to describe herd-years regarding their production level (average milk yield within 305 days MY) and their resilience and health status (percentage of short lactations of less than 90, 120 and 200 days PSL90, PSL120 and PSL200, percentage of cows with at least one test-day above 300,000 somatic cells/ml P300kcel, or with at least one clinical mastitis observed by the farmers PMacl).

Analyses. Pearson correlations were estimated between consecutive years. The association between LnVar and the herd-year descriptors was studied through Pearson correlations and using a one factor linear model (SAS ® GLM procedure), in which we tested the effect of classes of LnVar (5 classes, from very low to very high LnVar) on each herd-year descriptor.

Results and discussion

LnVar presented a high variability, with extreme values at more than 4 standard deviations from the mean and a coefficient of variation of 0.26 (Table 1). LnVar was quite repeatable across years (Table 2), which means that the profile of fluctuations in lactation curves of a given herd was only partially affected by one-time events. Correlations between herd-year descriptors and LnVar were low or moderate (Table 3). Herdyears with high LnVar tended to be more productive and more vulnerable to udder infections (correlations of 0.27 and 0.21 between LnVar and MY and P300kcel respectively).

All effects of LnVar classes on the herd-year descriptors were significantly different from zero (α <1‰). The tendencies mentioned before were confirmed, with large differences between classes illustrated by the contrasts with the middle class (Table 4). The average MY of the highest class was 1742 kg higher than that of the lowest one and 523 kg higher than that of the middle one. The risk of having at least one test-day above 300 000 cells/ml was 1.55 times higher in herd-years with very high LnVar than in those with very low LnVar (52.1 vs 33.6%). Differences were observed for PMacl, even though the correlation with LnVar was weaker. The percentage of short lactations was higher for both extreme classes, but the risk increased more after 120 DIM for classes with high LnVar than for those with low LnVar (+2.1 vs +0.8% between 90 and 200 days for herd-year classes with very high vs very low LnVar).

General discussion

Our indicator was based on the same principles as described in Poppe et al. (2020), with several differences. The first one was the use of monthly test-day records instead of daily data. Large differences could be observed between herd-years, even with less regular performances, and these differences were quite repeatable across years. The second originality was that the expected milk yields at each test-day were based on the effects estimated within a test-day genetic evaluation. Thanks to this approach, expected milk yields were adjusted for the cow genetic abilities (individual peak and persistency), and for the environmental effects estimated at a given stage of lactation. These parameters are currently available for any herd participating to milk recording and can be updated at each new evaluation. The relationship between LnVar and herd descriptors were consistent with Poppe et al. (2020): the greater the fluctuations in lactations (higher LnVar), the more productive the herds and the greater the risk of udder health problems (high somatic cell counts and more clinical mastitis (CM) events). For PMacl, the low correlation with LnVar and the fact that the effect did not increase between the two highest classes of LnVar was probably due to a lack of comprehensiveness of registered CM events in some herds (Govignon-Gion et al. 2012).

The relationship between the percentage of short lactations and LnVar was more complex to interpret, since lactations may have been closed for many reasons. A large part of very short lactations were probably due to a low production level, particularly in the herds with a low productivity, and thus in the class with very low LnVar. But Beaudeau et al. (1995) showed that early lactation (before the peak of lactation) and end of lactation were the main periods of decision making for culling. Thus short lactations closed after the pick (between 90 and 200 days) likely corresponded to involuntary culling, and the increase in occurrences of short lactations with high LnVar could be interpreted as a lack of resilience.

Conclusion

This study showed that even with monthly data, it is possible to build herd resilience indicators based on the fluctuations of lactation curves, and that the results of a test-day genetic evaluation can provide useful information for herd management. Further investigations should be undertaken, in order to assess the genetic variability of LnVar estimated at the cow level and whether this proxy could be used to select more resilient cows.

Table 1 .Descriptive statistics of the herd resilience indicator LnVar

 1

		N	mean	std	min	max
	LnVar	35,719	1.26	0.33	-0.12	2.97

Table 2 : Correlations between LnVar estimated in consecutive years.

 2

	2015-2016	2016-2017	2017-2018
	0.49	0.50	0.52

Table 3 : General characteristics of herd-year descriptors and correlations with LnVar

 3

						Cor. with
		Abbreviation	Unit	mean	std	LnVar
	Milk Yield	MY	kg	8719	1413	0.27
	% of short lact. (<90 days)	PSL90	%	1.4	3.3	0.03
	% of short lact. (<100 days)	PSL120	%	2.3	4.5	0.05
	% of short lact. (<200 days)	PSL200	%	4.9	7.5	0.08
	% of lact. with ≥ 1 test day with ≥ 300 000 cells	P300kcel	%	39.1	16.5	0.21
	% of cows with ≥ 1 clinical mastitis within 1 st parity	PMacl	%	11.1	13.4	0.04

Table 4 : Means of herd performance indicators in different herd-year classes based on LnVar (compared to the middle herd-year class, standard errors within brackets) 1

 4

			Classes of herd-years based on the LnVar level 2
		Very low	Low	Middle	High	Very high
	N	643	4 700	25 022	4 345	1 007
	MY	-1219 (55)** -685 (22)**	0	+466 (23)**	+523 (44)**
	PSL90	+0.7 (0.13)** +0.16 (0.05)**	0.0	+0.20 (0.05)** +0.3 (0.11)**
	PSL120	+0.8 (0.18)** +0.2 (0.07)	0.0	+0.4 (0.07)**	+0.9 (0.07)**
	PSL200	+1.5 (0.30)** +0.0 (0.12)	0.0	+0.9 (0.12)**	+2.4 (0.23)**
	P300kcel -4.9 (0.64)*	-4.1 (0.26)**	0.0	+6.2 (0.27)**	+13.5 (0.52)**
	PMacl	-2.8 (0.53)** -1.5 (0.21)**	0.0	+0.9 (0.22)**	+0.5 (0.43)
	1 *: Pvalue <10 -3 ;** Pvalue <10 -4 ; 2 Very low: ≤ 0.6; low : ]0.6; 0.93]; Middle: ]0.93 ; 1.59]; high: ]1.59; 1.92];
	very high: >1.92

Acknowledgement

We acknowledge European Union's Horizon 2020 Research and Innovation program GENTORE under grant agreement No. 727213, for financial support. In addition, we acknowledge Claudia Kamphuis (Wageningen Livestock Research, Wageningen, Netherlands) for her intellectual input, and French MROs for providing the data.