Bastien Fraudet
email: bastien.fraudet@pole-sthelier.com

Emilie Leblong

Patrice Piette

Benoît Nicolas

Louise Devigne

Marie Babel

François Pasteau

François Routhier

Philippe Gallien

SWADAPT2: benefits of a collision avoidance assistance for powered wheelchair users in driving difficulty

Keywords: Smart wheelchair, rehabilitation, neurological diseases

Purpose: In France, tens of thousands of people use a wheelchair. Driving powered wheelchairs (PWCs) present risks for users and their families. The risk of collision in PWC driver increases with severity of dis-ability and may reduce their independence to drive. The European ADAPT project has developed a robotic assistance add-on for PWCs to prevent collisions and improve their driving performance.

Materials and methods:

The aim of the SWADAPT2 study is to assess the benefit of this robotic assistance add-on arranged on a Standard Quickie Salsa M2 PWC in a population of PWC drivers with neuro-logical disorders and driving difficulties. Eighteen (18) participants tested the system on three circuits of increasing difficulty, with and without the robotic assistance add-on. Results: The benefit of the robotic assistance add-on was important especially on the more difficult circuits without impacting cognitive load or driving speed. The number of collisions was significantly reduced when using robotic assistance add-on from 2.16 to 0.36 on circuit 2 (p = 0.009) and from 7.3 to 1.33 on circuit 3 (p = 0.0009). Task load demand was not increased with the assistance. Conclusion: Finally, this system seems to be indicated to assist and improve driving safety for PWC drivers in driving difficulty. Evaluation was performed in controlled environments; therefore, further evaluation in real-world scenarios is needed to reach technology readiness.

IMPLICATION FOR REHABILITATION

This device is an effective technology to avoid collisions, especially for patients with neurological disorders in difficulty of driving. Several use cases can be considered: the equipment of drivers who are losing driving ability due to age evolution of their pathology, or anxiety; the equipment of users in driving training with difficulties, in order to facilitate access to users who are currently unable to drive.

Introduction

The World Health Organization (2008) estimated that about 65 million people use wheelchairs (powered or manual), which represents about 1% of the world population [START_REF]Guidelines on the provision of manual wheelchairs in less resourced settings[END_REF]. As reported by Kokosy et al. [START_REF] Kokosy | SYSIASS? an intelligent powered wheelchair[END_REF], the prevalence of wheelchair users is increasing in Western countries, estimated at 60-200 per 10,000. This prevalence is 92 per 10.000 in USA [START_REF] Steinmetz | Americans with disabilities: 2002[END_REF], and 90 per 10,000 in Canada [of which 14.8% are powered wheelchairs (PWCs)] [START_REF] Smith | Prevalence of wheelchair and scooter use among Community-Dwelling Canadians[END_REF]. In Europe, prevalence is 6.4 per 10,000 inhabitants in France [5], and 200 for 10.000 in Great Britain [START_REF] Sedgwick | Improving services for wheelchair users and carers. Good practice guide: learning from the wheelchair services collaborative[END_REF].

While the use of a wheelchair improves the quality of life of the person and their family, it also exposes them to certain risks. In 2006, 100,000 accidents involving wheelchair users were recorded in the USA [START_REF] Xiang | Wheelchair related injuries treated in US emergency departments[END_REF]. Edwards reported that the yearly accident rate of WC users in Australia was 21% [START_REF] Edwards | A survey of adult power wheelchair and scooter users[END_REF]. In the Chen study in Taiwan, 54.7% of subjects said they had experienced at least one accident in the past three years [START_REF] Chen | Wheelchair-related accidents: relationship with wheelchair-using behavior in active community wheelchair users[END_REF]. Tips and falls are the leading mechanisms of related injury, but accidental contacts with an immovable or mobile object or being represent 7% of the wheelchair-related accidents. The risk of collision accidents is one of the main problems reported due to environmental (obstacles, road quality) and human (difficulties linked to disability, or inappropriate behaviour) [START_REF] Kim | The status of accidents and management for electronic assistive devices among the handicapped[END_REF][START_REF] Henje | Obstacles and risks in the traffic environment for users of powered wheelchairs in Sweden[END_REF] factors, which can have major consequences for health and social participation [START_REF] Ummat | Nonfatal wheelchair-related accidents reported to the national electronic injury surveillance system[END_REF][START_REF] Mcclure | Wheelchair repairs, breakdown, and adverse consequences for people with traumatic spinal cord injury[END_REF].

PWCs are essential technical aids for many individuals, allowing them to maintain independence of movement and contribute to a satisfactory quality of life [START_REF] Brandt | Older people's use of powered wheelchairs for activity and participation[END_REF][START_REF] Davies | Changes in the quality of life in severely disabled people following provision of powered indoor/outdoor chairs[END_REF][START_REF] Pettersson | The value of an outdoor powered wheelchair with regard to the quality of life of persons with stroke: a follow-up study[END_REF]. But the risk of collision may increase with the level of disability. It can restrict its use thus resulting in limited mobility which further impacts daily autonomy and quality of life [START_REF] Cooper | Driving characteristics of electric-powered wheelchair users: how far, fast, and often do people drive?[END_REF][START_REF] Fehr | Adequacy of power wheelchair control interfaces for persons with severe disabilities: a clinical survey[END_REF][START_REF] Rushton | The potential impact of intelligent power wheelchair use on social participation: perspectives of users, caregivers and clinicians[END_REF][START_REF] Gallien | Quality of life of adults with cerebral palsy living in britanny[END_REF]. In this context, minimising the risk of collision via navigational assistance would allow people who are not eligible to use a PWC to have access to this option, or PWC users who have difficulties due to their disability to continue using their wheelchair. Patients suffering from visual disorders, cognitive slowness, or significant functional limb impairment may benefit from such a solution.

For several years, PWC navigation assistance using environmental sensors has been studied extensively by many laboratories, whether involving ultrasonic sensors [START_REF] Levine | The NavChair assistive wheelchair navigation system[END_REF][START_REF] Ragot | Coalas: a eu multidisciplinary research project for assistive robotics neuro-rehabilitation[END_REF][START_REF] Babel | HandiViz project: clinical validation of a driving assistance for electrical wheelchair[END_REF], infrared sensors [START_REF] Kokosy | SYSIASS? An intelligent powered wheelchair[END_REF][START_REF] Leblong | SWADAPT1: assessment of an electric wheelchair-driving robotic module in standardized circuits: a prospective, controlled repeated measure design pilot study[END_REF], cameras [START_REF] Mihailidis | An intelligent powered wheelchair to enable mobility of cognitively impaired older adults: an anticollision system[END_REF], or even lasers [START_REF] Demeester | Wheelchair navigation assistance in the fp7 project radhar: objectives and current state[END_REF][START_REF] Favey | Development of a new negative obstacle sensor for augmented electric wheelchair[END_REF]. However, few solutions have been brought to market especially because smartwheelchairs are considered as a " niche market" [START_REF] Simpson | Smart wheelchairs: a literature review[END_REF].There is a broad range of disabilities who can benefit from navigation assistance but several reasons limit their development as sensor's cost, lack of standard communication with commercial PWC, lack of clinical evidence, and clinician and user's acceptance [START_REF] Leaman | A comprehensive review of smart wheelchair past, present, and future[END_REF]. Most of the experiments were conducted on people without disabilities. Moreover, most of publications with PWC users included a limited number of participants [START_REF] Kim | The status of accidents and management for electronic assistive devices among the handicapped[END_REF][START_REF] Leblong | SWADAPT1: assessment of an electric wheelchair-driving robotic module in standardized circuits: a prospective, controlled repeated measure design pilot study[END_REF][START_REF] Leaman | A comprehensive review of smart wheelchair past, present, and future[END_REF][START_REF] Simpson | A prototype power assist wheelchair that provides for obstacle detection and avoidance for those with visual impairments[END_REF].

Only a few devices are available on the market. Braze and Smile Smart System are obstacle-warning systems [32,33]. Luci is the only one including obstacle detection and collision avoidance. These devices are perceived as simple and useful and reduce the mental load when driving PWCs [START_REF] Simpson | Smart wheelchairs: a literature review[END_REF][START_REF] Pellichero | Blind spot sensor sys-tems for power wheelchairs: obstacle detection accuracy, cognitive task load, and perceived usefulness among older adults[END_REF]. However, these solutions require the driver to process the information and then adjust his trajectory.

Under the scope of the ADAPT project (Assistive Devices for empowering disAbled People through robotic Technologies) [START_REF]ADAPT (Assistive Devices for empowering disAbled People through robotic Technologie[END_REF] a robotic assistance add-on capable of handling positive obstacles (collision avoidance module) was developed. The module is a semi-autonomous driving assistance system, with the module activated the PWC will stop on a frontal arrival in front of an obstacle. In the event of an angled arrival the PWC will autonomously circumvent the obstacle by skirting it. The SWADAPT1 study [START_REF] Leblong | SWADAPT1: assessment of an electric wheelchair-driving robotic module in standardized circuits: a prospective, controlled repeated measure design pilot study[END_REF] validated the feasibility, acceptability, safety and benefits of the anti-collision module in patient who were regular wheelchair users without any difficulty in using PWCs in daily life. Moreover, the use of robotic assistance add-on significantly reduced the risk of collision on the most complex circuit. In this second stage of the project (SWADAPT2), our aim was to evaluate the benefit of this robotic assistance add-on module for PWC users with driving difficulties comparing the use of the wheelchair with and without the detection system on the three circuits. We hypothesis that the use of robotic assistance add-on module in assessment days, 7 d apart, requiring them to navigate a circuit of increasing difficulty over a period of 15 d. The circuits were the ones that had been designed and used in the ADAPT project, described in the SWADAPT1 study [START_REF] Leblong | SWADAPT1: assessment of an electric wheelchair-driving robotic module in standardized circuits: a prospective, controlled repeated measure design pilot study[END_REF]. The scenarios of the three circuits were defined based on a survey (publication in progress) of 366 professionals who evaluated the level of difficulty of a list of 31 driving tasks synthesising data from different assessments and standardised programs (PIDA, WST and WSP) and the experience of professionals. The 3 levels of the 3 circuits were inspired by these data to include tasks corresponding to increasing difficulty (Table 1). Each circuit corresponded to a difficulty level, i.e., C1 low, C2 moderate, C3 high difficulty (Figure 2). Each assessment day comprised an initial interview (demographic questionnaire, presentation of the system), the time to discover the circuit, the time to test the circuit, and time for an assessment after each randomisation mode. The order according to which participants were tested on the circuit (with or without the assistance module) was determined randomly on each assessment day. Each test run on the circuits was preceded by five minutes of hands-on time with the PWC used for the test. Each circuit was tested three times consecutively in one or other of the modes (with and without activation of the robotic assistance add-on) whose order depended on the randomisation. A 30-min washout period between each mode corresponding to the completion of the questionnaires was performed. In total, each participant made 18 test runs; six on each circuit and three in each mode.

Outcome measures

The primary outcome measure was the number of collisions reported during each run. A collision was defined as any physical contact between any part of the PWC and any part of the circuit. Two occupational therapists independently assessed (by direct observation) the number of collisions during each run on the three circuits. They were unaware of which mode was being used.

In the event of disagreement between the two observers, the data retained were the data with the highest score. The outcome measure "number of collisions" retained for each experimental condition (with and without activation of the robotic assistance add-on) was the mean number of collisions from three runs of each of the circuits. The secondary outcome measures were:

the mean speed calculated over the three runs in each mode on each circuit (mean of the 3 runs); -Task load demand and mental demand by the raw NASA Task Load Index (NASA TLX) [START_REF] Hart | NASA-task load index (NASA-TLX); 20 years later[END_REF][START_REF] Grier | How high is high? A meta-analysis of NASA-TLX global workload scores[END_REF] and subscore. The raw NASA-TLX instrument is partitioned into six distinct subscales, namely mental demand, temporal demand, physical demand, performance, effort and frustration. Each of these subscales is assigned a numerical score ranging from 0 to 100. The NASA task load index is computed as the mean of the scores from the six subscales: usability of the add-on assessed via the Usability, Satisfaction and Ease of Use Questionnaire (USE), composed of 30 questions grouped in four dimensions: usefulness (8 items), ease of use (11 items), ease of learning (4 items) and satisfaction (7 items). Each item is measured by a 7-point Likert scale, the score for each dimension is out of 7 [START_REF] Lund | Measuring usability with the USE questionnaire[END_REF].

Task load demand and usability were assessed after three runs had been completed in each mode, for each of the three circuits.

Statistical analysis

As each circuit was run three times to obtain the score of collisions and run times, the mean of the three runs was calculated.

The mean for the number of collisions and time was used to respect the protocol of the first study [START_REF] Leblong | SWADAPT1: assessment of an electric wheelchair-driving robotic module in standardized circuits: a prospective, controlled repeated measure design pilot study[END_REF].

The statistical analysis related to these means. The other scores were only assessed at the end of the series of three consecutive tests with or without assistance. Statistical analysis was performed using R studio software, version 4.0.5 (2021), on matched data. Descriptive quantitative data included the mean, standard deviation, median and quartiles. The Shapiro-Wilk test showed that the sample was not normal for the main criterion (p < 0.0001).

The Wilcoxon test for matched samples was therefore used to compare the data. For the raw NASA-TLX data no pairwise comparisons were use and no weighted score was calculated. Comparison for condition with/without assistance, were assessed via paired Wilcoxon signed ranks.

Effect sizes were calculated using the Wilcoxon test and confidence intervals by bootstrapping. The significance threshold used was 0.05. The predictability of driving difficulty (WST-Q) on the safety gain of the robotic assistance add-on (difference between the number of collisions with and without assistance) was assessed using a linear regression model. A diagram presenting the average number of collisions measured on the 3 circuits C1, C2, C3. These results show that the difference in the number of collisions increases with the difficulty and becomes significant for the second circuit and multiplied by 5 for the C3.

Results

Population

Sixteen participants took part in the study, eight men and eight women with a mean age of 57 ± 13 years. Characteristics of the population are shown in Table 2. Fourteen participants took part in all the three tests on the three circuits. One participant did not complete the third test run on circuits 2 and 3 and one other participant did not complete the third test run on circuit 3 due to fatigue following the driving session.

Number of collisions

The first circuit did not present any major difficulties (driving in a wide corridor in forward direction, turning in a wide space, wide turns) (Table 3, Figure 3). Collisions were only reported in four participants. From the second circuit onwards, the use of assistance significantly reduced collisions from 2.16 (3.73) to 0.36 (0.9) (p= 0.009). For circuit 3, the most complex circuit with the maximum number of high-risk situations, 100% of users had collisions but the robotic assistance add-on significantly reduced the number of collisions from 7.30 (8.90) to 1.33 (1.40) (p =0.0009). The effect is large for circuit 2: r value=0.73, 95% CI [0.56-0.85]; and large for circuit 3: r value =0.83, 95% CI [0.68-0.88]. We fitted a linear model to predict "collision gain" with WST-Q score. The model explains a statistically significant and moderate proportion of variance (p = 0.044, adj. R2 = 0.21). Within this model, the effect of WST-Q score is statistically significant and negative (beta = 0.68, 95% CI [-1.34-0.02], p = 0.044).

Statistical analysis demonstrated none difference concerning efficacity of the assistance regarding hand laterality.

Duration of circuit

No significant differences were reported between the two modes (Table 4, Figure 4). The use of the robotic assistance add-on did not affect the completion time of the run in people with driving difficulties.

Task load demand and mental demand (NASA-TLX and subscore)

Task load demand was moderately high for the three circuits, regardless of the mode (Table 5, Figure 5). The introduction of robotic assistance add-on did not significantly change this task load demand, even if a downward trend was observed for circuits 2 and 3 in the assisted mode.

However, a closer analysis of the NASA sub-scores shows a significant difference of 11.6 points on the mental demand score, in favour of the assistance (p = 0.05).

Usability (USE)

Scores were high in the four dimensions demonstrating a good level of usability of the robotic assistance add-on in the context of the experiment, with or without the assistance module and without the module having an impact on the usability of the wheelchair (Table 6).

Discussion

The results obtained in this study are consistent with the data previously reported in the literature. However, while several studies report experiments and assessments with PWC users as part of an assessment of smart wheelchairs, most of these experiments were conducted on people without disabilities [START_REF] Kim | The status of accidents and management for electronic assistive devices among the handicapped[END_REF][START_REF] Leaman | A comprehensive review of smart wheelchair past, present, and future[END_REF][START_REF] Boucher | Design and validatyion of an intelligent wheelchair towards a clinically_functional out-come[END_REF][START_REF] Simpson | Voice control of a powered wheelchair[END_REF][START_REF] Aziz | HMM based automated wheelchair navigation using EOG traces in EEG[END_REF][START_REF] Faria | Evaluation of distinct input methods of an intelligent wheelchair in simulated and real environments: a performance and usability study[END_REF][START_REF] Lamti | When mental fatigue maybe characterized by event related potential (P300) during virtual wheelchair navigation[END_REF][START_REF] Li | Design of assistive wheelchair system directly steered by human thoughts[END_REF][START_REF] Js | Experimental study on a smart wheelchair system using a combination of stereoscopic and spherical vision[END_REF][START_REF] Rojas | Skills based evaluation of alternative input methods to command a semi-autonomous electric wheelchair[END_REF][START_REF] Sharma | Evaluation of semiautonomous navigation assistance system for power wheelchairs with blindfolded nondisabled individuals[END_REF][START_REF] Stansfield | A comparison of the efficacy of weight-shift vs. joystick control of a robotic mobility device by infants ages 5 to 10 months[END_REF][49][START_REF] Puanhvuan | Navigation-synchronized multimodal control wheelchair from brain to alternative assistive technologies for persons with severe disabilities[END_REF][START_REF] Rebsamen | A brain controlled wheelchair to navigate in familiar environments[END_REF][START_REF] Ron-Angevin | Brain-computer interface application: auditory serial interface to control a two-class motor-imagery-based wheelchair[END_REF][START_REF] Tsui | A self-paced motor imagery based brain-computer interface for robotic wheelchair control[END_REF]. A few publications report case studies of PWC users with a limited number of participants ranging from 1 to 9 people [START_REF] Kim | The status of accidents and management for electronic assistive devices among the handicapped[END_REF][START_REF] Leaman | A comprehensive review of smart wheelchair past, present, and future[END_REF][START_REF] Boucher | Design and validatyion of an intelligent wheelchair towards a clinically_functional out-come[END_REF][START_REF] Lamti | When mental fatigue maybe characterized by event related potential (P300) during virtual wheelchair navigation[END_REF][START_REF] Li | Design of assistive wheelchair system directly steered by human thoughts[END_REF][START_REF] Sharma | Evaluation of semiautonomous navigation assistance system for power wheelchairs with blindfolded nondisabled individuals[END_REF][START_REF] W€astlund | Evaluating gaze-driven power wheelchair with navigation support for persons with disabilities[END_REF][START_REF] Bastos-Filho | Towards a new modality-independent interface for a robotic wheelchair[END_REF][START_REF] Cheein | SLAM algorithm applied to robotics assistance for navigation in unknown environments[END_REF][START_REF] He | A P300-based threshold-free brain switch and its application in wheelchair control[END_REF][START_REF] How | Evaluation of an intelligent wheelchair system for older adults with cognitive impairments[END_REF][START_REF] Mcgarry | The smart wheelchair: is it an appropriate mobility training tool for children with physical disabilities?[END_REF][START_REF] Ceres | A robotic vehicle for dis-abled children. Providing assisted mobility with the PALMA project[END_REF][START_REF] Wang | Usability testing of multimodal feedback interface and simulated collisionavoidance power wheelchair for long-term-care home resi-dents with cognitive impairments[END_REF]. Only Ju et al. [START_REF] Ju | Vision based interface system for hands free control of an intelligent wheelchair[END_REF], Shiomi [START_REF] Shiomi | Effectiveness of social behav-iors for autonomous wheelchair robot to support elderly people in Japan[END_REF] and Pellichero et al. [START_REF] Pellichero | Blind spot sensor sys-tems for power wheelchairs: obstacle detection accuracy, cognitive task load, and perceived usefulness among older adults[END_REF] have tested their solution on cohorts of more than 10 participants with disabilities. This is one of the first studies involving a cohort of more than 10 participants with disabilities assessing smart wheelchairs. Most of the study population were powered electric wheelchair users with cerebral disabilities, only two participants had spinal cord injuries. In the case of brain damage, particularly supra-tentorial damage, cognitive elements often accompany motor difficulties making wheelchair driving more complex due to issues including attention deficit, executive-decision making or visual-spatial issues such as hemispatial neglect. Fatigue is also an important impairment, which can limit daily life activities. Two participants in our trial did not complete the study, because travel to participate in the study was finally too exhausting for them. The system under study is a robotic assistance add-on that does not require cognitive processing by the participant as it corrects the trajectory of the wheelchair automatically without user intervention. This further limits the risk of collision compared to warning systems that require action following the perception of the alert and therefore depend on the user's reaction time, which is often increased in the case of cognitive disorders. Our results tend to show that its effectiveness in preventing collisions does not impact either performance, cognitive load or tiredness as may be the case with other systems based on visual distance mapping [START_REF] Tomari | Development of smart wheelchair system for a user with severe motor impairment[END_REF] or auditory instructions [START_REF] Rathore | A novel multipurpose smart wheelchair[END_REF]. The robotic assistance add-on studied could reduce this cognitive load during the most demanding tasks. In addition, the user does not require a learning phase, which can be a lengthy and complex process in the case of cognitive disabilities. It is therefore perfectly suited to the target population with driving difficulties connected to central neurological injuries. Moreover, the regression results seem to show that the greater the driving difficulty, the greater the benefit of the robotic assistance add-on. The robotic assistance add-on is especially useful for drivers with major difficulties.

From a technological perspective, it is important to emphasise the easy interfacing of the system with a commercial PWC. Thus, unlike many driver-assistance solutions proposed in the literature [START_REF] Sivakanthan | Minireview: robotic wheelchair taxonomy and readiness[END_REF], neither the electronics of the chair nor the chassis have been modified for the automation. The proposed solution is therefore completely risk-free and easy to install on wheelchairs using R-net. Further work might be needed to generalise to other power wheelchairs.

In addition, the same PWC, uniquely configured (speed, margins for obstacle avoidance), was used by all participants to avoid any technological bias. Only the control interface was adapted to the abilities and habits of participants (simple joystick adapted as required for either a T-handle or ball control). The standardised configuration used for the study is therefore suboptimal from the perspective of the user: the chair used may differ considerably from the personal chair of the participant (motorisation, settings, finer adjustments). However, the performances achieved by the robotic assistance add-on in this study underline the ease of use, as seen in the USE scores. Finally, as no learning process is required, robotic assistance add-on is transparent to the user: the system is based on an intuitive cooperation between the robotic system and the user. It therefore does not affect the mental load. This is an important issue for the acceptance of any technological assistance.

Concerning limitations, first, the sample size was small and the length of driving experience and disability level varied widely (5 participants only had a single WST item lower than 2 compared to 14 items for other participants) as did the profile of disorders, which makes it difficult to generalise the results to all users with driving difficulties.

Second, a single PWC model was used in the experimental sessions, for standardisation purposes. However, it is well known that driving performance is also linked to the adaptation of the WC to the needs of the participant. The performance achieved may have been biased by this choice.

In addition, the results were obtained under circuit conditions which, although they tend to reproduce environment-related tasks, are still conditions close to laboratory conditions and do not greatly reflect the reality of the daily lives of users. The transposition of the results into everyday life is still debatable at this stage.

Conclusion

This study demonstrates the value of the robotic assistance add-on in preventing collisions with positive obstacles for PWC users with driving difficulties in controlled situations. Further evaluation in real-world scenarios is needed to reach technology readiness.

In addition, to achieve full mobility autonomy inside and outside, the risks of tipping and falling due to the presence of negative obstacles in urban situations should be considered [START_REF] Favey | Development of a new negative obstacle sensor for augmented electric wheelchair[END_REF]. Outside of the home, many situations may involve a risk of tipping over (edges of steps, pavements, etc.). Considering negative obstacles is therefore an important additional stage in driving autonomy. The ADAPT project will therefore continue to develop robotic assistance add-on to prevent risks linked to negative obstacles.

Figure 1 :

 1 Figure 1 : standard conditions for people with driving difficulties reduces the number of collisions, without impacting driving speed or mental workload.

Figure 2 .

 2 Figure 2. Evolution of collisions on the 3 circuits (W; with assistance, W/O: without assistance).

Figure 3 .

 3 Figure 3. Evolution of running time on the 3 circuits. (W: with assistance, W/O: without assistance). A diagram presenting the completion time of the course measured on the 3 circuits. The figure shows that the duration increases in the 3 circuits but in an almost parallel way with a difference which remains not significant for the 3 circuits

Table 5 .

 5 Comparison for condition with (W) vs without assistance (W/O) for raw NASA-TLX. Nasa 1 Mental Demand, Nasa 2 Physical Demand, Nasa 3 Temporal Demand, Nasa 4 Own Performance, Nasa 5 Effort, Nasa 6 Frustration Level, NTLI NASA Task Load Index. Signif. codes: 0 ' *** ' 0.001 ' ** ' 0.01 ' * ' 0.05 '.' 0.1 ''1.

Figure 4 .

 4 Figure 4. Evolution task load and mental demand on the 3 circuits (W: with assistance, W/O: without assistance).A diagram presenting the evolution of the mental load through the global score of the NASATLX and its mental demand sub-score. It shows a non-significant tendency that the mental load increases more the difficulty of the circuits for the condition without assistance in comparison with the use of the anti-collision sensors

Table 1 .

 1 The different tasks included in each circuit.

	Circuit	Task description
	1	Wide corridor (2.5 m) Forward
		Wide turn
		U-turn on site Reverse
	2	Fixed obstacle on the ground to be circumvented
		Low slope (5 °) to go down and up
		Wide corridor/wide doorway
		Fixed obstacle on the ground to cross
		Low and moderate slope (5 ° and 10 ) ) to go down
		and up
	3	Fixed obstacle in height
		Emergency stop
		Stop with precision
		Walk along a wall
		Narrow corridor (1.5 m)
		Table: setting up Double stain
		Elevator simulation: forward entry and reverse exit
		Restricted space
		Moving obstacle to bypass

Table 2 .

 2 Characteristics of the population studied.

	Participants	Gender	Age	Pathology	Laterality	Number of items with WST-Q ability
						score <2
	1	Men	68	Stroke	Left	17
	2	Women	45	Stroke	Right	11
	3	Men	56	Cerebellar syndrome	Left	12
	4	Women	32	Severe visual disturbances of unknown central origin	Right	1
	5	Men	76	Quadriplegia	Left	14
	6	Women	34	Cerebral palsy	Left	15
	7	Men	72	Cerebellar syndrome	Right	9
	8	Men	43	Quadriplegia	Right	1
	9	Women	51	cerebellar syndrome	Right	5
	10	Women	62	Stroke	Left	12
	11	Women	59	Stroke	Right	6
	12	Men	66	Stroke	Right	1
	13	Men	73	Stroke	Right	1
	14	Women	50	Stroke	Right	11
	15	Women	59	Brain injury	Left	1
	16	Men	64	Parkinson	Right	3

Table 3 .

 3 Comparison of the number of collisions on the three circuits between without (W/O) and with (W) assistance, * p < 0.05, ** p < 0.01, *** p <

	0.001
			Collision
		Mean (sd)	Mean (sd)	Wilcox test
	Circuit	W/O	W	P value
	C1	0.39 (1.01)	0.06 (0.18)	0.18
	C2	2.16 (3.73)	0.36 (0.9)	0.009**
	3	7.30 (8.90)	1.33 (1.40)	0.0009***

Table 4 .

 4 Comparison of time to completion on the three circuits between without (W/O) and with (W) assistance.

			Time (s)
		Mean (sd)	Mean (sd)	Wilcoxon
	Circuit	W/O	W	test
				p value
	C1	109.8 (34.7) 95.8	105.5 (30.9) 95.0	0.97
	C2	148.4 (84.5)	149.8 (76.4)	0.83
		116.3	113.5
	C3	264.1 (97.2)	227.3 (113.9)	0.13
		194.6	234.8

Table 6 .

 6 Comparison of USE sub-scores without (W/O) and with (W) assistance.

		Mean (sd)	Mean (sd)	Wilcox
	Circuit	W/O	W	test
				p value
	Utility
	C1	5.66 (0.90)	5.72 (1.15)	0.70
	C2	5.56 (1.28)	5.53 (1.46)	0.81
	C3	5.49 (1.18)	5.57 (1.30)	0.87
	Facility use
	C1	6.04 (084)	6.09 (0.72)	0.90
	C2	5.91 (0.75)	6.07 (0.72)	0.15
	C3	5.99 (0.85)	6.13 (0.79)	0.63
	Facility learning
	C1	6.25 (0.72)	6.20 (0.78)	0.88
	C2	6.27 (0.58)	6.23 (0.86)	0.49
	C3	6.16 (0.71)	6.33 (0.87)	0.19
	Satisfaction
	C1	5.

80 (1.13) 6.50 (0.82) 0.59 C2 5.66 (1.04) 5.42 (1.31) 0.16 C3 5.31 (1.75) 5.36 (1.43) 1.00

Acknowledgements

Thanks to Estelle Ceze, Marie Dandois, Estelle Poupelin, for their help in setting up the experiments.

Funding

This study is founded by INTERREG FEDER publics funds, in the context of the ADAPT project (adapt-project.com) and European Regional Development Fund. F. Routhier is a Senior Research Scholar of the Fonds de recherche du Québec -Santé (FRQS).

Note

1. https://www.legifrance.gouv.fr/codes/section_lc/ LEGITEXT000006072665/LEGISCTA000006154978/ #LEGISCTA000025457387

Availability of data and materials

The dataset uses and analysis during the current study are available from the corresponding author on reasonable request.

Authors' contributions

The authors cited have all contribute to this trial. MB, FP and LD have participated to technical the development of smart PWC. They all participate to the technical support during the trial. BN, PG and EL participate to the enrolment of the participants. PG and EL participate to the protocol writing. BF participate to the protocol elaboration and coordinate the trial. PP was responsible of statistical analysis. EL, PG, and BF participate to the analysis of the results. BN, PG, MB, PP, FR and BF participate to the writing and to the reviews of this article.

Ethical approval and consent to participate

This study was approved by the ethics committee Comité de Protection des Personnes CPP Sud Méditerrannée IV the 11th 2019 (n °2019-A01306-51). This study was registered the 6 October 2020 on ClinicalTrials.gov, ID: NCT04259151 https://clinicaltrials.gov/ct2/show/NCT04259151?term=gallien&d raw=2&rank=6

ORCID

Bastien Fraudet http://orcid.org/0000-0003-0472-4738 Marie Babel http://orcid.org/0000-0001-6425-389X François Routhier http://orcid.org/0000-0002-5458-6233

Consent for publication

All authors consent to this publication

Disclosure statement

The authors declare that they have no competing interests.


Yann Busnel

Leo Lavaur

Federated Learning × Security in Network Managements

Federated learning (FL) is a machine learning (ML) paradigm that enables distributed agents to learn collaborative models without sharing data. In the context of network security, FL promises to improve the detection and mitigation of attacks, notably by virtually extending the local dataset of each participant. However, one of the major challenges of this recent technology is the heterogeneity of the data used by the participants. Indeed, some participants with very different monitoring contexts could penalize the global model. Furthermore, identifying malicious contributions is made more difficult in heterogeneous environments.

In this tutorial, we will first present the fundamentals of federated learning, then focus on its use in network monitoring, and more specifically, in collaborative intrusion detection (Federated Learning-based Intrusion Detection System-FIDS). Secondly, we will address some of the open research questions in this context [LPBA22], before focusing on the problem of training data heterogeneity. Finally, we will discuss the security of FL architectures, and more specifically, the problem of poisoning attacks. All these parts will be illustrated by hands-on exercises, guided step by step throughout the tutorial.

Bio. Léo Lavaur (Graduate Student Member, IEEE) received the engineering degree in information security from the National Engineering School, South Britany (ENSIBS), Vannes, France, in 2020. He is currently pursuing the Ph.D. degree in cybersecurity with the Engineering School, IMT Atlantique and the Chair on Cybersecurity in Critical Networked Infrastructures (Cyber CNI), Rennes, France. During his studies, he also worked in industry with Orange Cyberdefense as a part-time Employee for three years, where he worked on application security, and Wi-Fi rogue access-point detection and location.

He now studies the collaboration in security systems, and how to share data without compromising security. His current research focuses on the challenges of using federated learning as a framework for collaborative intrusion detection systems. In particular, he works on the detections of malicious contributions in heterogeneous environments, as well as on the creation of datasets for evaluating FIDS in heterogeneous settings.

Audience and background requirement

This tutorial is open to anyone (MSc to Faculty) with a basic knowledge of machine learning (particularly neural networks) and Python programming.

Tutorial content

This tutorial is structured as an alternation between lectures and practical exercises. Lectures will take about 20 to 30 minutes each, with the exercises filling the rest. This program is divided in three parts:

(i) fundamentals of FL, (ii) FL for collaborative security, (iii) security of FL architectures. Fundamentals of FL. First, we will introduce the audience to FL and some of its applications, from general framework to the context of network management. In the practical part, learners will be introduced to Flower, an open-source FL framework, and to existing datasets for network security. The objective is to lay the foundations for the rest of the tutorial, and to make sure that everyone has the necessary knowledge to follow.

FL for collaborative security. In this part, we will focus on the use of FL in the context of network security, and more specifically, in collaborative intrusion detection (Federated Learning-based Intrusion Detection System-FIDS). The lecture will give an overview of the challenges of collaborative security in FL, with a focus on the heterogeneity between clients. In the practical exercise, we will implement common models on standard IDS datasets and observe these challenge through small experiments.

Security in collaborative FL. Finally, the last lecture will address some challenges of running FIDS in terms of security. Depending on the exposure of the federation (open or closed entrance, trustworthiness of the participants, etc.), such collaborative architectures can be vulnerable to various types of attacks. The lecture will especially focus on the problem of data poisoning, and how it can be mitigated. In particular, we will talk about the difficulty of detecting such attacks in heterogeneous environments, with leads from the literature, and mention some of our current research on the topic. The practical exercise will be a hands-on experiment on data poisoning, where attendees will be able to observe the impact of such attacks on the models, and how existing works try to mitigate them.

Materials and requirements

Hand-out

The following material will be provided to the attendees after the tutorial:

• the slides decks of the lectures (three parts),

• commented Jupyter notebooks (also three) for the different practical exercises, with the necessary code and data.

Hands-on

For the practical exercises, attendees will need to have a working Python environment, with a recent version of Python and a set of common libraries (NumPy, Pandas, Matplotlib, TensorFlow, Flower, . . . ). Actual dependencies will be provided before the conference. However, attendees must be warned beforehand that issues with their environment will not be addressed during the tutorial. Alternatively, the Jupyter notebooks will be available on Google Colab, so that attendees can run them without installing anything on their machine.

Depending on NoF's organizing committee, access to a locally hosted JupyterHub should be considered to avoid depending on the quality of the Internet connection (see infrastructure requirements below).

Infrastructure requirements

Multiple options are possible for the practical exercises: a) either the attendees will run the notebooks on their own machine, in which case they will need a working Python environment (see above), b) either the notebooks will be hosted on Google Colab, in which case attendees will need a Google account and a web browser; this option is more convenient for the attendees, but requires a good and stable Internet connection, c) or the notebooks will be locally hosted on a JupyterHub (or alike) instance, in which case attendees will also need a web browser; this options requires an instance that can accommodate all attendees runing ML tasks, ideally with GPU support.

a faculty, including 6 years as a full professor at IMT Atlantique and member of the IRISA laboratory, he now oversees all research and innovation activities in line with Institut Mines-Télécom's strategy. He contributes closely to the definition of strategic orientations and to the operational management of the institution. He also represents the Executive Board internally and externally with its partners in the research environment.

He holds an Habilitation to Supervise Research and a PhD respectively from the École


Aless Hosry

Vincent Aranega

Nicolas Anquetil

Stéphane Ducasse

Pattern matching in Pharo

Keywords: Pattern matching, Smalltalk, Object-oriented programming

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Pattern matching is a computational technique used to identify and analyse recurring structures or patterns within data and enables the extraction of meaningful information from the data [START_REF] Hills | Navigating the wordpress plugin landscape[END_REF].

Pattern matching could vary between string searching or regular expressions, which are supported in multiple programming languages such as Java, Javascript and C# [START_REF] Friedl | Mastering regular expressions[END_REF], matching over trees of objects [START_REF] Hoffmann | Pattern matching in trees[END_REF] like ASTs, or object matching using functional programming languages like Scala [START_REF] Emir | Matching objects with patterns[END_REF].

Such matchers are needed in Pharo for tasks like optimisation [START_REF] Atkinson | Effective pattern matching of source code using abstract syntax patterns[END_REF], by identifying specific patterns in code defined by developers to reduce resource consumption and enhance performance. Additionally, matchers can help in error detection by detecting common programming errors [START_REF] Atkinson | Effective pattern matching of source code using abstract syntax patterns[END_REF] and applying some code refactoring in order to improve software quality and reliability. Moreover, pattern matching is reliable for querying deeply recursive structures like nested data [START_REF] Hills | Program analysis scenarios in rascal[END_REF] that are very common during software analysis or data exploration in fields like data mining.

IWST 2023: International Workshop on Smalltalk Technologies, August 29-31, 2023, Lyon, France aless.hosry@inria.fr (A. Hosry); vincent.aranega@inria.fr (V. Aranega); nicolas.anquetil@inria.fr (N. Anquetil); stephane.ducasse@inria.fr (S. Ducasse)

Based on these requirements, we present in this paper the "RBParseTreeSearcher" matcher that is already present in Pharo as well as another, more generic matcher that we developed recently and named "MoTion" [START_REF] Motion | [END_REF].

The first one is the pattern matcher used by the RefactoringBrowser infrastructure [START_REF] Anquetil | Transformation-based refactorings: a first analysis[END_REF], it allows to define patterns to match them with Pharo source code AST. The RefactoringBrowser also comes with a RBParseTreeWriter that allows to modify the source code matching a given pattern, but we will not explore this part here as we are only interested in the pattern matching capability.

The second pattern matcher is MoTion [START_REF] Motion | [END_REF], a recently created generic pattern matcher that allows to express patterns on any set of objects, their classes, and their properties. The focus of MoTion is the expressiveness of patterns, offering a large set of functionalities.

In this paper, we present some of the existing approaches and how they differ from each other in Section 2. Then in sections 3 and 4 we present the syntax of the matchers followed by examples. The actual comparison takes place in section 5, before concluding the paper in Section 7.

Pattern matchers characteristics

Many programming languages offer pattern-matching libraries. Some of them are GPL (General Purpose Languages) like in Python, Haskell, Rust and Scala, while others are DSL (Domain Specific Languages) like with Rascal.

Table 1 presents a list of characteristics we identified in several existing implementations of pattern matching languages:

Object Matching [START_REF] Di Ruscio | Model transformations[END_REF] is the fact of matching any object based on its class and properties. The expected values of the properties can be themselves patterns to be matched against the actual value returned when the unary-message is called on real objects.

Structural Pattern [START_REF] George | Type-safe model transformation languages as internal DSLs in scala[END_REF] refers to a pattern that captures and matches the "shape" of a given object or data using subpatterns.

Anonymous Variables [START_REF] Schmitt | An evaluation of domain-specific language technologies for code generation[END_REF] refer to tokens that imply the existence of a value without capturing it.

List matching [START_REF] Schmitt | An evaluation of domain-specific language technologies for code generation[END_REF] offers the ability to describe the general shape of a list.

Negation [START_REF] Kirchner | Anti-pattern matching[END_REF] consists of specifying a pattern that the data should not match.

Unification [START_REF] Rascal | [END_REF] consists of using the same variables multiple times in a pattern that all match the same (repeated) data.

Nested Match [START_REF] Rascal | [END_REF] consists of expressing a pattern about a direct inner object.

Deep Match [START_REF] Schmitt | An evaluation of domain-specific language technologies for code generation[END_REF] allows to search for an object in a structure (or hierarchy) without having to bother about the depth to which the searched object is.

Recursive Search [START_REF] Emir | Matching objects with patterns[END_REF] is similar to Deep Match but assumes a hierarchy of similar objects, or at least objects that have the same property. For example, one could search for an object having a specific "child" without knowing at what depth this object, and thus its child, are.

Can yield all results [START_REF] Rascal | [END_REF] means that the result contains all data matching the pattern and not just the first match found. Many approaches in the literature applied pattern matching, whether for General Purpose Programming Languages (GPL) or Domain Specific Programming Languages (DSL) [START_REF] Klint | Rascal: A domain specific language for source code analysis and manipulation[END_REF]. Table 1, summarises those approaches according to the characteristics described previously in this section.

RBParseTreeSearcher

In this section, we present the pattern matching language of the Pharo refactoring framework as implemented in RBParseTreeSearcher. We will first introduce the syntax of the language, and then we will show different usages with Pharo methods of the RBParseTreeSearcher class.

Syntax

The syntax of this language relies on specific symbols, allowing to express patterns over any source code of a Pharo image:

(') Back-tick. It is used to match any single node. For example: "'someName asString" can match message asString sent to any receiver, disregarding its name. It can match Pharo source code like "self asString" and "aParam asString".

('#) Literal pattern nodes. To verify that the matched node is a literal, a back-tick can be followed by the hash sign. "'#lit size" is an example where '#lit can match an integer 3, a string foo or even a collection such as #(a b c). It will not match "self asString".

('@) List pattern nodes. Is used to match zero, one or more nodes in the AST. For example, "|'@args1 t1 '@args2|" returns a successful match with | t1 t2 t3 t4| where args1 will be empty and args2 matches t2 t3 t4.

(") Double Back-tick. It is used to perform a recursive search. This implements the deep match characteristic. It entails searching for patterns not only on the surface level of the source code, but also examining their internal structure. For example, ""@vars + 1" matches any selector followed by + 1, additionally, it will internally check if this selector is already constructed by another selector followed by +1, such as (myNum + 1) + 1 + 5, where the first match of '@vars' is myNum + 1 and the second is myNum found by the deep match.

('.) Statement pattern nodes. To match statements, a developer can use a backtick followed by a period. Such patterns '.Statement1. match a single statement in Pharo such as "self assert: myVal size equals: 11." . It can also be combined with the list pattern ('@.) to search for a list of successive statements, such as "'@.statements" which will successfully match "x := 1. y := 2. z := OrderedCollection new.".

('{ }) Block Pattern Nodes Is a free-form test where, inside the curly braces, one puts a Pharo block, receiving a node as a parameter and returning a boolean whether this node matches or not. For example: "'{:node|node isVariable and: [node isGlobal]} become: nil" is a pattern that matches a message become: with a nil argument, where the receiver is a global variable.

Examples

After describing the syntax and capabilities of Pharo source code matchers over blocks, literals, statements and so on, we will go through how to use this syntax with a handful of methods defined in RBParseTreeSearcher in this section. While this paper focuses on matching in Pharo, it is important to note that the same syntax can be used with a couple of methods implemented in RBParseTreeWriter to perform some source code transformations. 5 searcher executeTree: (RBParser parseExpression: 'self put').

Listing 1 contains an example of source code pattern matching in Pharo. In line 1, searcher variable is declared as an RBParseTreeSearcher object. The message #matches:do: is sent to this variable in line 2 to start the match, where matches: accepts the pattern expressed using the syntax introduced in the previous section, and do: accepts a block of code that is executed only when the match succeeds. On success, all matches are stored in a dictionary (context), where each key represents a part of the pattern, like "@rcv" and the value contains the matched source code. In cases where the key matches multiple source code fragments, they are encapsulated in a list and stored in the value in pairs with the convenient key. In this example, when the block is executed, it enables storing all matches of context in contextDictionary.

To start matching patterns, the developer needs to use method #executeTree: that takes as input a parsed source code object, such as line 5, using RBParser parseExpression.

MoTion pattern matcher

In this section, we are going to present MoTion, a pattern matching language for objects that relies on specific symbols and a couple of methods to allow matching over objects in a Pharo image.

Syntax

Unlike the previous pattern matching language, MoTion syntax does not have the ability to explicitly represent the Pharo AST being searched for, except for literals. In simpler terms, while the old language enables the creation of patterns that directly describe the syntax of Pharo, MoTion is based on a different approach. In MoTion, representations are based on object types and, if needed, certain methods that correspond to objects in Pharo. This matching capability extends beyond Pharo language objects and includes any other object like Java objects represented in Pharo using the FamixJava metamodel.

Literal matching MoTion is able to match literals (boolean, string, symbols and numbers) by concretely expressing them like true, 1, #foo and 'Pharo Playground'. In order to make it more performant, MoTion also allows matching regular expressions for strings. For example: Pharo.*ground can match with Pharo Playground.

(%) Object match A basic Object match must first include the type of the Object to match as defined in Pharo such as Color%{}, RBMessageNode%{} or FamixJavaModel%{}.

(<=>) Properties A match could be more specific, by specifying the type of the object to match followed by the properties assigned to the specific values. A property represents a predefined method in the object class only if such methods have a return. For example: RBComment % {#size <=> 2} is a pattern that could match any comment that is empty, because the size of comments in Pharo must be bigger than 2 taking into consideration the double quotation marks.

(<∼=>) Negation Sometimes, it may be easier to search for objects that match a pattern, which properties don't fit specific values, instead of specifying numerous properties. For that we implemented the negation symbol that helps developers to specify such patterns easily. For example: RBComment % {#size <∼=> 2} is a pattern that could match any comment that is not empty.

(%%) Subclasses This is again a deep match operation. Pattern expression could be more flexible by using the double %% to match properties of subclasses, such as RBLiteralNode %%{#value <=> 1} that could match any object that extends directly or indirectly RBLiteralNode class.

({.}) Lists More than one property could be specified for the match, by encapsulating all properties in a list after defining the type. For example: RBLiteralNode %%{#value <=> 1. #sourceText <=> #'a text here' } which allows the usage of value and #sourceText.

(@) WildCards Wildcards are used to match a property associated to any value. The importance of wildcards in MoTion is their ability to save and return such values to be treated in following steps using Pharo. For example: RBLiteralNode %%{#value <=> #'@anyValue'}, where @anyValue could be anything associated to #value.

Composed patterns

Examples

Listing 2 is an example of MoTion and how we can use it to match a package. Lines 1 to 8 contain the pattern defined using MoTion syntax. Line 9 is matching this pattern with Talents package as it is required in MoTion using #match: message. The return type of this match is a MatchingContext which contains isMatch of type Boolean, and matchingContexts which contains a list of a bindings dictionary that in turn contains the wildcards (since their values are unknown) as keys, and the matched objects as values. However, MoTion also provides a way to retrieve only the bindings of specific wildcards such as in line 10. The return type of collectedBindings is a list of bindings, each of which has a dictionary of keys and values. If multiple matches exist, this means that multiple bindings are returned in the list.

As for the structure of the pattern, between lines 1 and 8 , it's a pattern of type RPackage which properties are encapsulated in a list. The first property #classes is associated to a wildcard @allClasses (line 2), to store all the classes of the matched package and retrieve them in line 10 using message #collectBindings:for:. The second property is constructed of a MoTion path, as we are interested in methodDict of definedClasses which in turn encapsulates a subpattern. As a summary, listing 2 is a an example of a pattern to be matched with any package in Pharo, which methods contain the selector #ifTrue:ifFalse.

We mentioned earlier that MoTion can match objects, and we are using it to match Java, XML ans SQL Objects parsed in Pharo. Listing 3 is an example of how we can use it to retrieve XML nodes based on their attribute name and value, which cannot be done using RBParseTreeSearcher syntax.

Comparison

By leveraging MoTion's syntax, users can specify complex patterns to match objects based on various criteria, as we chose MoTion syntax to be expressed declaratively. In terms of capabilities, MoTion has been impacted by other matchers like the ones stated in 2 in addition to RBParseTreeSearcher such as deep search and anonymous variables. Since both matchers have some common capabilities, we decided to perform a comparison of matching using the same Pharo 11 image for both of them. We took some basic source code templates, some of which are search rules implemented as examples in the rewrite tool.

Syntax and Expressiveness

• The first example, shown in Listing 4, checks if the source code has a selector #ifTrue:ifFalse:.

With RBParseTreeSearcher, specifying patterns to detect the receiver and the list of arguments inside the blocks is mandatory, while in MoTion, this specification could be skipped as the developer is only interested in knowing if the selector is invoked in this code or not. • Patterns of the second example in Listing 5, are inspired by the third rule of the rewriter tool, whose purpose is to check if nil exists in ifNil to remove it by applying a transformation rule. For this rule, the RBParseTreeSearcher pattern is more efficient as it is able to precisely position nil inside ifNil:. This cannot be done by MoTion, as it cannot precisely determine the nil position in the used blocks. • The third example, shown in Listing 6, is inspired by rule 8 of the rewriter tool, which consists of matching a select: method that contains a receiver followed by not, to be replaced in a later stage by reject:. Again, the precision of not position is mandatory in this example, which is possible by RBParseTreeSearcher as it is able to express the possible existence of temporary variables and statement lists, followed by not positioned at the end inside the block. While that is not possible in MoTion, as the properties declared inside the pattern and associated with some values or subpatterns, do not take into consideration their order.

Matching characteristics

After comparing the speed of match for both languages, we list in Table 3 the characteristics explained in section 2 and if they are applied for each one of them: Based on both comparisons, it is evident that RBParseTreeSearcher exhibits superior performance compared to MoTion, despite the latter being a more generic pattern matching language.

Future work

MoTion lacks for the moment two important features: a debugger and a pattern generator. Currently, we use MoTion to extract source code to do software analysis for cross-language applications, but the expressiveness of such patterns is error-prone, especially while precising the properties of a MoTion path, which sometimes leads us to lose time while expressing such patterns. At the moment, we are employing a simple technique that involves minimising MoTion paths and starting to determine whether or not we have found a match. However, a debugger will be able to automate this process and address the incorrectness of such paths and what properties may be incorrect, thus making it faster and more effective for developers to use. Additionally, we intend to develop a pattern generator that will enable developers-particularly those who are unfamiliar with MoTion-to provide it with the source code they want it to search for. MoTion will then be able to automatically generate patterns that represent such source code, enabling developers to match it against the packages or models they want to search for.

Conclusion

To conclude, we present in this paper two pattern matchers in Pharo. The first one, RBParse-TreeSearcher syntax, is able to match Pharo AST and has the ability to apply transformations using the rewriter tool. The second one, MoTion, implemented recently for matching over objects, including Pharo ASTs, given their types and properties. Both matchers were compared, and the experiment has shown a faster performance for RBParseTreeSearcher over the same patterns, being more specific. However, we also realised that, given the flexibility of the syntax of MoTion, a higher ability to match objects, disregarding their complexity, and is able to support structural patterns, lists, object matching, deep matching, negation, and many other characteristics compared with other tools implemented in the literature by different programming languages.

Listing 1 :

 1 Pattern Matching over source code sample 1 searcher := RBParseTreeSearcher new. 2 searcher 3 matches: '@rcv put' 4 do: [ :aNode :answer | contextDictionary := searcher context ].

Listing 2 :

 2 Pattern Matching over source code sample 1 pattern := RPackage % { 2 #classes <=> #'@allClasses'.

3 # 4 # 5 # 6 } 7 } 8

 345678 'definedClasses>methodDict' <=> CompiledMethod % { 'ast>allChildren' <=> RBMessageNode % { 'selector>value' <=> #ifTrue:ifFalse: }. 9 pattern match: #Talents asPackage. 10 collectedBindings := pattern collectBindings: {#allClasses} for: (#Talents asPackage).

Listing 3 : 3 #

 33 Pattern Matching over source code sample 1 XMLNodeList % { 2 #'_>attributes' <=> XMLAttribute % 'name' <=> #'Field' .

4 #

 4 'value' <=> #'myButton1'.

Table 1

 1

	Existing approaches(Pattern matching languages)
	Characteristics / Languages Rascal Haskell Scala Python	Java a	Rust
	Object Matching	x	x	x	x	Matching Types	x
	Structural Pattern	x	x	x	x	planned	x
	Anonymous Variables	x	x	x	x	planned	x
	List Matching	x
	Negation	x	x
	Unification	x
	Nested Match	x	x	x			x
	Deep Match	x	x		x		x
	Recursive Search		x
	Can yield all results	x
	a https://dev.java/learn/pattern-matching/

  Pattern searching may require searching for complex structures, for that, MoTion allows declaring patterns constructed also of subpatterns, such as: RBBlockNode %{ #statements <=> RBValueNode %% { #value <=> 2 } } where #statements is associated to another subpattern. RBMessageNode that returns an object of type RBSelectorNode, which in turn has a property named value. This helps expressing patterns in a more flexible way, by accessing directly a children's property. It is important to note, composed path allows accessing at the same time only one direct children, but the path could be extended to as many subchildren layers as the developer needs, like: definedClasses>methodDict>ast>allChildren. Anonymous properties usage is when the developer doesn't know what is the exact name of the property, or when she/he wants to access a descendant children without caring about the predecessors. In this case, multiple matches could result if multiple properties have the same descendant children. For example: RBMessageNode % { #'_>parent' <=> @anyParent } could return matches for receiver>parent and selector>parent as both have parent as a property. Matcher save The main purpose of this matcher is to encapsulate patterns and subpatterns into variables, in order to be able to retrieve their values after a successful match. For example: RBMethodNode % #'children*' <=> RBMessageNode % #'selector>value' <=> #ifTrue:ifFalse: as: #MyMessageNode where #MyMessageNode contains matching objects of type RBMessageNode.

	(*) Recursive search It enables searching for the same property in many children layers,
	specially when the developer doesn't know what is the depth of such children to pre-
	cise it in a composed path. For example: RBMethodNode % #'children*' <=>
	RBMessageNode % #'selector>value' <=> #ifTrue:ifFalse:	which
	allows searching recursively for all properties named children in different descendent
	layers, to match any one with selector #ifTrue:ifFalse:.

Block Matcher they are used to generate new matchers dependently on the current object being matched and/or variables captured during the matching process, such as: ObjectA %{ #lint <=> [ :collection| collection includes: 4] onCollection } can match objA lint: #(1 2 3 4 5 6 7) because the list contains 4 as described by the block inside the pattern.

Conditional Matcher they are used to write complex conditional matchers dependent on the current object being matched and/or variables captured during the matching process

To make it easier to represent advanced patterns, we developed the MoTion path, which is used solely to express properties within a pattern, allowing the direct access of children's properties instead of defining subpatterns in patterns.

(>) Composed path MoTion paths are composed out of multiple properties as descendent children, which means they are not methods declared in the same class, but they are properties of the return type object. For example: RBMessageNode % { #'selector>value' <=> #ifTrue:ifFalse: } #selector is a property of (_) Anonymous property (as:)

Table 3

 3

	Characteristics comparison
	Characteristics / Languages MoTion RBParseTreeSearcher
	Object Matching	x
	Structural Pattern	x	x
	Anonymous Variables	x	x
	List Matching	x	x
	Negation	x
	Unification	x	x
	Nested Match	x
	Deep match	x
	Recursive path	x	x
	Can yield all results	x	x

Listing 4: Match #ifTrue:ifFalse:

1 "--RBParseTreeSearcher --" 2 '@receiv ifTrue: [ '@args1 ] ifFalse: [ '@args2 ]. 3 4 "--MoTion --" 5 RBMessageNode % { 6 #'selector>value' <=> #ifTrue:ifFalse:

Listing 6: Replace #select: by #reject: While both languages excel in pattern matching capabilities, RBParseTreeSearcher has been recognised for its superior speed compared to MoTion as it is dedicated to matching only Pharo ASTs. It is optimised for this only, while MoTion is entirely generic and can match any object at any depth, implying more computation and thus more time to execute.

Matching speed