Panagiotis Gkikopoulos

Valerio Schiavoni
email: valerio.schiavoni@unine.ch

Josef Spillner

Analysis and Improvement of Heterogeneous Hardware Support in Docker Images

Keywords: Docker, containers, trusted execution, hardware dependencies 3

Docker images are used to distribute and deploy cloud-native applications in containerised form. A container engine runs them with separated privileges according to namespaces. Recent studies have investigated security vulnerabilities and runtime characteristics of Docker images. In contrast, little is known about the extent of hardware-dependent features in them such as processor-specific trusted execution environments, graphics acceleration or extension boards. This problem can be generalised to missing knowledge about the extent of any hardwarebound instructions within the images that may require elevated privileges. We first conduct a systematic one-year evolution analysis of a sample of Docker images concerning their use of hardware-specific features, including those for virtualisation, acceleration and security. To improve the state of technology, we contribute novel tools to manage such images in heterogeneous environments. Our heuristic hardware dependency detector and a hardware-aware Docker executor give early warnings upon missing dependencies instead of leading to silent or untimely failures. Our dataset and tools are released to the research community.

Introduction

Portability is a desirable property in cloud computing [START_REF] Martino | Applications portability and services interoperability among multiple clouds[END_REF][START_REF] Petcu | Portability and interoperability between clouds: challenges and case study[END_REF]. Virtual machine images, container images and other executable artefacts ought to be flexibly deployed across clouds [START_REF] Binz | TOSCA: Portable Automated Deployment and Management of Cloud Applications[END_REF], migrate from the cloud to the edge [START_REF] Carrasco | Live migration of trans-cloud applications[END_REF], or be confined within differentiated cloud security zones [START_REF] Schinianakis | Security Considerations in 5G Networks: A Slice-Aware Trust Zone Approach[END_REF]. Nevertheless, limitations to portability arise from the differences in the underlying heterogeneous hardware. Apart from targeting the basic processor architecture, new cloud service paradigms such as accelerated computing or secure computing demand support for further hardware extensions abstracted as shared resources [START_REF] Yeh | KubeShare: A Framework to Manage GPUs as First-Class and Shared Resources in Container Cloud[END_REF]. Any hardware thus requires support in the boot process (BIOS/EFI), operating system, virtualisation layers and application execution stacks, as well as in the applications and their constituent artefacts (e.g., images). Among the hardware features of interest to cloud application engineers are FPGAs, GPUs and nested virtualisation [START_REF] Ren | Nosv: A lightweight nested-virtualization VMM for hosting high performance computing on cloud[END_REF][START_REF] Shepovalov | FPGA and GPU-based acceleration of ML workloads on Amazon cloud -A case study using gradient boosted decision tree library[END_REF][START_REF] Tarafdar | Designing for FPGAs in the Cloud[END_REF], as well as security-increasing hardware.

Secure (confidential) cloud computing is one of the emerging concepts affected by reduced portability: tenants offload computation to third-party untrusted providers without having to worry about security issues typically associated with cloud offloading [START_REF] Herardian | The Soft Underbelly of Cloud Security[END_REF]. Over the years, this concept has been mapped to concrete secure architectures involving monitoring and intrusion detection [START_REF] Modi | A survey of intrusion detection techniques in cloud[END_REF], algorithmic proofs on data, trusted boot [START_REF] Johnson | Titan: enabling a transparent silicon root of trust for Cloud[END_REF], physical security including hardware security tokens and modules [START_REF] Coppolino | A comprehensive survey of hardware-assisted security: From the edge to the cloud[END_REF] and policy languages. Recently, hardware-based trusted execution environments (TEEs) enabled outsourcing the processing of confidential data with high privacy requirements [START_REF] Brito | Secure end-to-end processing of smart metering data[END_REF] towards untrusted clouds.

Mapping this concept to hardware requires support for special CPU instructions as well as appropriate configuration of hypervisors and other execution parts. Several vendor-specific instruction sets exist nowadays in processors available in the consumer market, as well as those offered by cloud providers [2,[START_REF]Introducing Google Cloud Confidential Computing with Confidential VMs[END_REF]. Specifically, we mention Intel Software Guard Extensions (SGX) [START_REF] Costan | Intel SGX Explained[END_REF], AMD Secure Enhanced Virtualisation (SEV) [START_REF] Kaplan | AMD memory encryption[END_REF], or ARM TrustZone [START_REF] Amacher | On the performance of ARM TrustZone[END_REF][START_REF] Pinto | Demystifying ARM TrustZone: A comprehensive survey[END_REF].

In most cloud environments, Docker containers become the standard de facto, as application developers migrate towards integrated platform services, e.g., IBM Code Engine, Amazon ECS, Azure Container Service and Google Container Engine. Research on heterogeneous hardware support for container execution has been limited to few aspects, and in particular has not covered TEEs. For highly security-and privacy-sensitive software applications, such as those in the domains of e-health, banks or smart metering, the use of TEEs offers many benefits. To drive their adoption, it is necessary to encapsulate the use in containerised form. Yet container runtime support for heterogeneous hardware in public clouds is still lacking, in particular for secure execution. This is surprising given that certain features are today available to providers of cloud infrastructure-as-aservice. For instance, all major cloud providers offer instances with SGX-/SEVcapable CPUs, nevertheless access to consumers is either limited or disabled. More specifically, Azure offers SGX/SEV capabilities with their Confidential Compute instances, while IBM or Alibaba have them enabled only for their bare metal instances. AWS and Google do not provide SGX-enabled instances, as the feature is disabled in their systems' BIOS. 3 In general, no cloud provider natively supports a container runtime that makes use of SGX. We believe this situation is going to fundamentally change over the next few years, and in that perspective, the research focus will shift to provide efficient support in the application stacks and artefact management tools, nowadays largely container-based.

To allow a Docker container to utilise a hardware-specific feature of the host system, the relevant device driver or kernel module needs to be explicitly mounted to the container at runtime. Some features, such as SGX, can be configured to run in simulation mode in the absence of supporting hardware. Base images that offer the relevant development tools for these features are sometimes provided by the hardware vendors themselves (e.g., Nvidia Docker [START_REF]NVIDIA Docker: GPU Server Application Deployment Made Easy[END_REF]), other companies (e.g., SCONE [7,[START_REF] Arnautov | SCONE: Secure Linux Containers with Intel SGX[END_REF]) or by members of the developer or research community. For the SGX use-case, the Graphene Secure Container Environment (GSCE) [START_REF]Graphene Secure Container Environment[END_REF] aims to wrap the standard Docker engine to allow standard images to run their applications within SGX enclaves, although this is in preliminary stages of development.

While our analysis shows that only few Docker images require specialised hardware at the time of writing, this is expected to change in the future. Already now, the discoverability of hardware in the form of CPU architectures per tag is limited, leading to issues in mixed environments. Making conscious use of the hardware features requires knowledge about them, which is presently absent from container images and handling tools and motivates our research. By consciously leveraging specific hardware types, augmented images can be invaluable to certain sectors, e.g., Highly Information Sensitive Computing (HISC), High Performance Computing (HPC) and FPGA-hosted blockchain-as-a-service [START_REF] Cho | Possibility of HPC Application on Cloud Infrastructure by Container Cluster[END_REF][START_REF] Florin | FPGA based architecture for securing IoT with blockchain[END_REF], enabling the integration of containers to their niche workloads.

The contributions of this paper are fourfold. We introduce a systematic analysis of the content of Docker images with emphasis on heterogeneous hardware, especially on TEEs for security, GPUs for acceleration, and nested virtualisation. In contrast to existing empirical works, our analysis follows a three-staged process: metadata inspection, image inspection, and dynamic runtime behaviour inspection. We also contribute augmented metadata that reflects the analysis results, and an improved hardware-aware Docker executor hdocker that parses the metadata to increase upfront assessment about the likelihood of hardwaredependent execution failure. We follow an open science approach. Our tools and datasets are released and available from https://doi.org/10.5281/zenodo.

4531795.

Roadmap. This paper is organized as follows. In §2, we provide a more comprehensive background on processor architectures and Docker container images.

§3 describes our three-step methodology. We present our evaluation strategy and experimental results in §4. In §5, we present our proposed extensions. We cover related work in §6. Finally, we conclude and present future work in §7.

Background

Processors and Hardware Heterogeneity

At the most fundamental level, hardware support means the ability to execute on a given processor architecture. Public clouds typically include amd64 (x86-64) and arm64, with minority occurrences of i386, ppc64el (IBM) or mipsel (Loongson). However, discussions of heterogeneous hardware refer to a broader set of features, such as specific instruction sets. When supported by BIOS/EFI, hypervisor and operating system, applications can typically rely on more than 100 unique CPU flags, e.g., sse3 for streaming operations or avx for vectoring. This also includes hardware-assisted TEEs, i.e., Intel SGX and AMD SEV or hardware-assisted virtualisation technology (i.e., Intel VT-x, AMD-V, HVM, etc.). Similarly, another group captures support for expansion devices or cards. This became increasingly relevant in recent years, by the usage of GPUs for high-performance computing, machine learning and simulations. We include in this group support for fast/low-latency disks (e.g., NVMe non-volatile memories) and network links (e.g., InfiniBand).

Distribution of CPU architectures in DockerHub images

Fig. 1: Distribution of images types in an ∼11'000 images non-random sample collected as of February 4 th , 2021. X-axis: processor architecture.

Docker Images

Since its introduction in 2013, Docker emerged as one the most popular cloudnative software artefacts and as such an integral part of modern DevOps operations Several frameworks and development environments are now available as drop-in solutions using Docker, significantly reducing the overhead of both setting them up and orchestrating them.

Images can be distributed in two ways. The first largely adopted method is using a container registry, the largest one being DockerHub. 4 There are private registries, curated by specific vendors5 , which incorporate stricter standards, i.e., built-in security scanning of all images motivated by the the several security issues found on public registries [START_REF] Shu | A Study of Security Vulnerabilities on Docker Hub[END_REF]. The second distribution method is to include the Dockerfile in a publicly accessible code repository (e.g., GitHub), for users to build the image themselves [START_REF] Cito | An Empirical Analysis of the Docker Container Ecosystem on GitHub[END_REF].

Docker has support for multiple CPU architectures, namely x86, x86-64, ARM, ARM64, PowerPC 64 LE and IBM's POWER and Z architectures. We fetched and analyze a sample of the publicly accessible Docker images on DockerHub, constituted by approximately 11'000 images (as we detail later in §3). We report these results in Figure 1 (also released to the research community, see Appendix 7). Unsurprisingly, x86-64 leads by a large margin with 48% of the images. Interestingly, IBM Z (S390X in Figure 1) is second most popular (with ∼15%). We observe that ARM64 is the fastest trending image type, after x86-64, showing a 1.7% monthly increase (Figure 2). Docker has recently introduced an experimental multi-architecture builder in which several versions of an image, compatible with multiple processor architectures are built simultaneously, thus speeding up the process of introducing compatibility for different architectures.

Metadata available from the official registry provides basic overview metrics, such as supported architectures and OS versions, as well as the number of images and tags within a repository. However, global statistics cannot currently be obtained from DockerHub, as the API endpoint for the global catalog metadata is disabled. Utilization of Docker images in contexts that require specialized hardware is now an emergent use-case, varying from Nvidia GPUs to

0 1 / 1 1 / 2 0 1 9 0 1 / 0 1 / 0 0 1 / 0 3 / 2 0 2 0 0 1 / 0 5 / 2 0 2 0 0 1 / 0 7 / 2 0 2 0 0 1 / 0 9 / 2 0 2 0 0 1 / 1 1 / 2 0 2 0 #AMD64
1300 1400 1500 1600 1700 Intel SGX-compatible CPUs, though adoption appers to be at an early stage, judging from the number of repositories and their omission from the list of official images. They require the host to have the correct hardware and driver support installed, and are thus limited in their reach to end users, but provide the ability to leverage Docker's advantages for applications that require specialized hardware features, such as secure execution and GPU-accelerated HPC. Still, metadata does not reflect hardware dependencies, and that makes such repositories difficult to detect with automated means, which is why we searched by specific vendors (namely Nvidia and Intel) and hardware features (CUDA and SGX) heuristically to create the sample for the evaluation of hardware support.

0 1 / 1 1 / 2 0 1 9 0 1 / 0 1 / 2 0 2 0 0 1 / 0 3 / 2 0 2 0 0 1 / 0 5 / 2 0 2 0 0 1 / 0 7 / 2 0 2 0 0 1 / 0 9 / 2 0 2 0 0 1 / 1 1 / 2 0 2 0 #S390X 10
0 1 / 1 1 / 2 0 1 9 0 1 / 0 1 / 2 0 2 0 0 1 / 0 3 / 2 0 2 0 0 1 / 0 5 / 2 0 2 0 0 1 / 0 7 / 2 0 2 0 0 1 / 0 9 / 2 0 2 0 0 1 / 1 1 / 2 0 2 0 Linux Windows

#Linux and #Windows

Methodology

The methodology followed to assess the hardware support in Docker images is divided into three steps. The first one (Figure 3-) consists in automatically monitoring the main DockerHub repository to retrieve a representative sample of the most used images. The metadata from the sample images is then stored and analysed for information on any specific hardware they support or require.

The second step (Figure 3-) dives deeper into the images and attempts to find any traces of hardware-specific binaries or configuration files. Finally, the third one (Figure 3-) performs basic manual runtime testing of a targeted selection of Docker images from DockerHub that use specific hardware features, to assess their quality and maturity.

The automated sampling of DockerHub metadata uses a two-tier approach. The search starts with the official Docker images, collected in a private library repository. The metadata from this repository is collected and added to the dataset. For each entry in the resulting data, we assume each image to correspond to an organisation, which maintains its own repository. For example, the image nginx is controlled and maintained by a corresponding nginx organization. We thus repeat the search for each of these possible organisations, adding the data returned (if any) to the dataset. This process essentially creates a shallow family tree of two levels, stemming from the official images. This serves to effectively increase the sample size by an order of magnitude, granting us a higher number of images to investigate. This selection process is scripted and both it and the metadata analysis runs nightly on a scheduled monitoring setup.

Compared to typical random sampling, this method has the advantage of specifically targeting repositories within DockerHub that are considered of highquality/high-profile, as their maintainers are either verified or certified publishers. It should be noted that the goal of this sampling is to feed the next steps with potential targets, not to obtain global metadata statistics for Docker Hub as a whole. As such, the statistics are meant as an indication of hardware support in the official and related repositories and do not represent a study of Docker Hub as an ecosystem.

Currently, the metadata provided by DockerHub's API does not provide any insight on whether or not an image requires specific hardware to be present on the host in order to function. A possible hardware features field could rectify this. In the present state of the metadata, the only way to select images with specific hardware requirements beyond CPU architecture is to rely on the web front-end's text search function, a rather cumbersome and unreliable approach. For example, a search of the keyword 'SGX' with the intention of discovering images that utilise Intel SGX, will also yield images submitted by users with the characters 'sgx' in their username. Naturally, such a search will exclude any images that use the hardware but don't include it in their name or description.

However, due to the relatively small number of images using targeted hardware technology, it is still possible to hand-pick a sample and assess them heuristically for typical quality metrics, such as compatibility, documentation and best practices. For the sake of illustration, we restrict the choice of the target technologies to: (1) Intel SGX, as a secondary processor architecture feature with high significance for security-conscious use cases, and (2) support for Nvidia GPUs, arguably the most common example of heterogeneous computing power. For the former, adoption is still rather limited. We believe this to change as SGX drivers have just been up-streamed into the mainline Linux kernel 6 . For the latter, adoption is more wide-spread, with many individual user-contributed repositories, so the search is narrowed down to the images contributed by the hardware vendor themselves, and restricted to static analysis.

Evaluation

We ran three separate experiments, one for each of the aforementioned methodic steps. Figure 4 gives an overview about the experiments, the resulting augmented metadata and its use in specific container and cloud management tools.

Metadata collection. We setup automated long-term monitoring and tracking of Docker container images via the global Microservices Artefact Observatory. 7 The observatory creates execution schedules for each registered monitoring tool, and shares these tools with other nodes within a federated cluster architecture for highly reliable observation and metadata retrieval. The dockerhub-collector tool periodically requests DockerHub's public API to retrieve metadata on the 'library' repository. This repository is unique: it is curated by DockerHub itself and contains 'official images', i.e., the most useful, popular and high-quality images available. Using this data as a starting point, we identify 'sister repositories', i.e., attempt to see if the developer of each image maintains their own repository, for which we request metadata. This selection process is integrated into the tool and automated. It increases the sample from the 164 repositories of the official set to ∼1200 repositories.

The continuous metadata collection has been running on each machine in the cluster daily, starting on November 11, 2019. The data snapshots obtained by each machine are compared for inconsistencies and then aggregated into a single dataset to analyse the hardware trends. The images with SGX and Nvidia support are selected manually in irregular intervals, based on a search of the repository for the specific hardware feature as explained before. The final lists describing the samples, after filtering out duplicates, images without any version and irrelevant repositories, are included in the dataset to ease reproducibility. Thus, we curated multiple lists of images as February 2021 snapshot for the evaluation: full library and associated images (∼11'000), strict library subset (164), SGX (67) and Nvidia [START_REF] Villari | Osmosis: The Osmotic Computing Platform for Microelements in the Cloud, Edge, and Internet of Things[END_REF]. We applied static scanning to the last two, and dynamic assessment to the last.

Image scanning. To gain further insights into the hardware-related aspects of container images, we developed imagexplore, a tool to uncompresses all layers of an image and recursively search for the occurrence of certain file, directory and content patterns. These come from a knowledge base created with file glob patterns as well as text and binary symbols hinting at the presence of hardware-specific features. Matches result from the installation of the SGX toolkits, Nvidia device drivers, USB devices or other hardware-related software leaving traces in the system. For example, an SGX base image needs to contain the SGX SDK. Thus, toolkit files can be detected in a predictable manner to confirm the presence of the SDK. Extending the knowledge base with additional patterns for different hardware devices enables the detection of images that utilize them, giving information on potential deployment issues due to hardware incompatibility. Evidently, this experiment leads to suspicions but not always to verified cases due to false positives. Hence, our method encompasses the manual verification of any edge cases. Furthermore, the scanning encompasses all files in the /dev file system, as those are not supposed to be part of any container image but their accidental addition may reveal further insights. This scanning phase is performed for all the automatically retrieved library and SGX images.

Image invocation. Beyond the static testing, we conduct dynamic runtime invocation on the SGX images to find out the actual use of any TEE-related operation. This test is runs on an SGX machine using an Intel Core i7-8650U. We categorised the SGX images into (1) base images and (2) those for applications or tools. We assessed them on the presence of documentation, instructions and the ability to initialise on an SGX-compatible machine. It is important at this stage to define what 'initialise' means in this context. For an application or tool, this is trivial: we expect some program output or the successful initialisation of a service. For a base image, we expect to setup a functional development environment when we run the image in interactive mode. This was achieved by inspecting the image to ensure the SDK and relevant dependencies are present. In the case of curated images, code samples are provided in the documentation that can be used to test the image. Due to the small number of SGX images, we allowed a minimal troubleshooting, which we define being able to run the images by just following the instructions (if any). In case of errors, we see if it is straightforward to resolve, e.g., mounting a file in a volume or specifying a command-line argument. If not, the image is deemed as not working, although its usability mainly depends on incomplete (or lack of) documentation. The minimal configuration possible for an image without instructions or other forms of documentation is to run it with no options besides mounting the SGX-related virtual devices from the host (i.e., /dev/isgx and /dev/mei0). For base images, this proved sufficient on the majority of occasions, as the images contained all the development tools they needed except for the hardware driver component.

Results

Metadata collection results. The automated monitoring of Docker Hub's public metadata gives the basic overview of processor architecture and operating system support discussed above. While not novel in itself, we further consider the amount of activity on the chosen sample during the same time period. 0 1 / 0 9 / 2 0 1 9 0 1 / 1 1 / 2 0 1 9 0 1 / 0 1 / 2 0 2 0 0 1 / 0 3 / 2 0 2 0 0 1 / 0 5 / 2 0 2 0 0 1 / 0 7 / 2 0 2 0 0 1 / 0 9 / 2 0 2 0 0 1 / 1 1 / 2 0 2 0 0 1 / 0 1 / 2 0 2 1

#Users

Active users per day

Start of monitoring data volume per day, as well as the number of unique usernames that appeared in each day's data, extracted from the same dataset. The goal of this observation is to ensure that our sample does not come from an inactive subset of Docker Hub, and thus reflects recent trends. Despite this being a small subset of approximately 1200 repositories, it gives a sense of the activity and data throughput per repository in Docker Hub. In the observed period, the total amount of data pushed to these repositories was ∼23TB. Image scanning results. We run the imagexplore tool on three sets of container images: (1) 67 SGX candidates, (2) 36 Nvidia candidates, and (3) 164 official library images as subset of the sample whose metadata we continuously retrieved over multiple months. Due to the absence of a :latest tag or nonpublic images, not all pulls succeed, thus these numbers are slightly reduced especially for less maintained non-official images for which non-default tags have therefore been recorded. All layers of all images are unpacked on disk for the analysis. We expect the tool to indicate 100% SGX and Nvidia dependencies in the first two sets (minus false positives), and 0% any hardware dependency in the third set (minus false negatives). Table 1 compares the results. Among the SGX candidates, four use the name coincidentally but do not contain any SGX-related code. Similarly, among the suspected Nvidia images, four contain code to run the Kubernetes-based EGX AI platform that is offered by Nvidia but do not contain any hardware-related code themselves. Among the library images, three are operating system distributions with support for USB devices that are successfully detected, whereas the vast remainder are pure application containers. The average scanning time per image already present locally is 7.0 s for library images, 15.1 s for Nvidia images and 30.3 s for SGX images on a server with Xeon E3-1270 CPU @ 3.80GHz. The main contributor to the significant difference is that most library images are rather tidy base images whereas especially the SGX images contain many layers with thousands of added files.

Concerning the /dev file system, the official images show better quality compared to the SGX images. However, in both sets, a lot of superfluous files were found. The Nvidia images are quality-wise in between with still a few of such files. Most of them mirror the standard device files added automatically by Docker, whereas almost as many consist of various other files to access audio devices, RAM disks, shared memory and other hardware. We suspect careless creation of images by snapshotting running container instances without proper post-execution cleanup of device files is the main reason. This hypothesis is supported by the occasional leftover of temporary files (/tmp, /var/tmp) in both sets of images. Table 2 compares the device file findings, with the optimal metric being 0 in all rows.

Image invocation results. The mentioned categories yield 33 base images (49.25% of total), 29 apps/tools (43.28%) and 5 images (7.46%) whose functionality could not be determined due to lack of documentation. The latter ones are excluded from the percentage calculations that follow. As for quality metrics, 47 of the images (75.81%) initialised successfully when tested and only 14 of them (22.58%) had any documentation or instructions.

Considering Docker Hub's limitations on making images private, the bulk of the undocumented images are likely experiments that were not meant to be shared. Even within these 67 images, a certain degree of deduplication was possible. Upon manual inspection 28 of the images were derivatives of others in the same set, of which 18, based on their functionality, were duplicated of earlier versions of other images. Examples include several variations of the SGX base image, which provides the SGX SDK and Platform Software (PSW) and an example 'hello world' application, cementing the observation that many images available were simply the results of users experimenting with the technology, or following tutorials. The lack of documentation and the amount of 'hello world' duplicates in the sample is a clear indication that the majority of images that use the SGX technology are experimental, and thus adoption of the technology is in its infancy on the Docker ecosystem.

In terms of observed errors among the 15 failures, there were image initialisation errors for 4 images and an enclave initialisation for 1. Others were application-specific errors. It is important to mention that as with any heuristic evaluation, the testing methodology can affect the final result and as such, the 15 failures have to be treated as an upper bound. As a secondary experiment, we attempted to run the tools that ran successfully, but without mounting the SGX devices. For them, 8 out of 15 ran successfully in simulation mode, with only two 'hello world' applications and an SGX-specific stress testing tool failing due to enclave initialisation errors. The 4 remaining failures were instances where the output of the program made it difficult to understand if initialisation was successful, i.e., possibly false-negatives.

The high success rate of the base images, even those with no documentation, also has a simple explanation. These images usually only include the SGX dependencies (the SDK and PSW) and typically some language specific dependencies for development. Thus, generically running them interactively by simply mounting the SGX device drivers is expected to yield a high degree of success. The spreadsheet used to track this heuristic evaluation is available in the publicly released dataset.

Images with support for Nvidia GPUs are far more numerous, potentially up to 1411 image repositories in our latest snapshot. We note that the company maintains 2 distinct organisation accounts (nvidia and nvidiak8s, respectively with 22 and 12 repositories), the latter focused on Kubernetes-related images. A common characteristic of both is the almost complete absence of documentation within Docker Hub itself. Instead, all relevant documentation is available in 's Github repositories, where the source code for these images can also be found. The absence of links from the Docker Hub repositories to the ones in Github however, means that the only reliable source of information on these images and their usage is 's Github. This is by no means an oddity, as typically Docker Hub is used to store images for public distribution and serves as a medium for users that wish to use a specific tool without building from source code manually, one of the main advantages of Docker. In that context, only having minimal documentation on Docker Hub (usually related to differences in using the image compared to running a tool natively) makes sense, as the main source code repo is responsible for housing the full documentation.

Listing 1.1: Hardware features extensions.

{ 2

" platform " : { 3 " architecture " : " amd64 " , 4

" os " : " linux " , 5

" features " : [ 6 " sse4 " 7 ] } } Listing 1.2: Support for heterogeneous hardware sources.

1 { 2 " platform " : { 3 " cpu " : { 4
" architecture " : " amd64 " , 5

" features " : { 6 " SGX " : " supported " , 7 " sse4 " : " required "

8 } 9 } , 10
" hardware " : { 11 " GPU " : " nVidia " 12 } , 13

" os " : " linux " 14 }}

Augmented Metadata

As mentioned earlier, Docker images built to utilize specialized hardware can benefit from augmented metadata to include hardware requirements. Such images are still a relatively small niche within the ecosystem. However, additional metadata can benefit users attempting to deploy them, as a clearer picture can be obtained by the Docker client on whether the image can be expected to function in the target system. To this end, we propose hardware-specific fields be added to the metadata of Docker registry entries. Furthermore, with Docker Hub's new rate-limiting policy (i.e., 100 image pulls every 6 hours), pulling an image simply for the sake of inspecting is problematic for free-tier users: with better metadata, operators can make informed decisions about image pulls ahead of time. Note that part of the additional information we propose to include is contained in the experimental image manifest v2, schema 2 of the Docker registry API specification [4] (see Listing 1.1, features element). Evidently, this implementation has some limitations. First and foremost, the image manifests are not available via the public API. As a consequence, one must pull the image and inspect it manually, a process that is hard to automate and requires storage space and network bandwidth for then potentially non-executable images. For instance, docker run will currently pull an AMD64 image on ARM before complaining about incompatible binary formats. Secondly, in terms of hardware, only CPU architectures and instruction sets are considered. Consequently, one cannot identify if an image uses GPUs or FPGAs from its manifest alone. Finally, CPU architecture variants and features are written to the manifest manually but cannot be verified during validation. This leaves the inclusion of this information at the discretion of the developer and the validation up to the end user. Thus, we propose an extension of the platform information that distinguishes CPU architecture and features, as well as other hardware devices supported. Listing 1.2 shows an example in augmented JSON format that serves as downwardcompatible replacement for the current Docker registry metadata. We argue that it is important to distinguish a hardware feature as supported, e.g., its func- tionality can be emulated/simulated if the hardware component is missing), or required, e.g., the container will fail without it. Moreover, specific hardware support from the host needs to be passed through to the running container. Hence, rather than replicating pass-through parameters in all scripts and composition documents (Listing 1.3), we argue for tightly binding them with the container metadata. Similar to how permissions are confirmed by users of mobile phone applications, administrators can interactively approve applications based on displayed host device access permissions. In addition, some containers require volumes to be mounted, or access to the Docker daemon socket, to be indicated in the extended metadata structure.

Improved Container Image Tooling

Finally, we introduce hdocker, a hardware-aware wrapper around the docker run command, to perform several tasks that streamline the use of Docker containers across heterogeneous hardware architectures. Specifically, hdocker can:

-Report on the availability of tags per architecture and architectures per tag.

-Check whether CPU flags and hardware devices are present and activated, beyond the standard CPU architecture and operating system. -Check whether device files and volumes are appropriately declared to be mounted in the invocation parameters. -Inform the user with clear actionable advice in case of unsupported features.

-Automate the analysis (using imagexplore) and decisions if asked to do so and if possible. The hdocker tool is metadata-driven, as it parses the augmented metadata curated from our experiments. Unless cached locally, it downloads all container image layers, runs imagexplore over all images, and store the resulting JSON metadata files. If the registry uses our augmented schema to retain this information, end users would not have to perform the image pull and analytics to obtain the hardware requirements of the image and hdocker could configure the hardware pass-through automatically.

Beyond the designed and implemented hdocker CLI, we also envision further tools to assess the metadata in a similar way. Among them are autonomous container migration tools that work as target node filters in heterogenous computing continuums (i.e., cloud/edge/fog/IoT or osmotic settings [START_REF] Villari | Osmosis: The Osmotic Computing Platform for Microelements in the Cloud, Edge, and Internet of Things[END_REF]).

Discussion

While Docker images that support or require specialised hardware still comprise a very small share of the total available images, we argue that their significance to industries that make use of heterogeneous or specialised hardware justifies communicating support for such features in an image's public metadata.

Our proposed support is nevertheless not a simple addition to the metadata schema. There are certain requirements for making its adoption meaningful.

Docker CLI support. The hardware features would have to be specified by the user through the Docker CLI during a build, or detected by the Docker builder. The latter is harder to implement, but would enforce the hardware specification, whereas developers would neglect specifying the hardware requirements.

Dockerd support. When attempting to run an image with specific hardware requirements that are not met, the Docker daemon would need to alert the user of the issue, rather than hdocker.

Docker Registry support. The hardware-related metadata would have to be part of the public Docker registry API, so that end-users can make informed decisions on the images they deploy ahead of time. The need for this is accentuated by the rate limit introduced by Docker Hub recently, forcing operators to be mindful of image pulls they make.

Related Work

Analyzing and understanding large container datasets offers substantial insights on current trends among practitioners and DevOps engineers' best practices. In [START_REF] Zhao | Large-Scale Analysis of the Docker Hub Dataset[END_REF], authors produce a large-scale dataset of more than 450'000 Docker images by crawling Docker Hub, downloading and decompressing images and analysing their contents. The dataset is populated with file-level metrics such as compression ratios, file types and sizes, and content-level metrics, i.e., programming languages, compressed files and database systems. Despite rich metadata including deduplication metrics, the underlying OS or architecture features are ignored. Moreover, the dataset is not made available, forcing the research community and ourselves to implement, deploy and run our own crawler to get complementary insights. While our automated monitoring is on a smaller scale, we produce and release a curated dataset that provides historical metrics by monitoring at regular intervals over a longer period of time. Our dataset also serves as an example of the type of insights that could be obtained by applying our methods to other repositories, such as those maintained by specific organisations.

Approximate Concrete Execution [START_REF] Byrne | ACE: Just-in-time Serverless Software Component Discovery Through Approximate Concrete Execution[END_REF] applies binary analysis to container images used in serverless platforms such as Google Cloud Run and AWS Fargate. It uses function-level fingerprinting to identify security problems in an early stage, based on a database associating fingerprints to such issues. The same technique could be used to fingerprint hardware dependencies. For simplicity, we look at container images at a coarse-grained level -if any script or application therein depends on a specific hardware feature, no matter if this is run on startup or just placed accidentally in the image, we consider the dependency to exist.

Several container orchestration tools have been recently proposed specifically for heterogeneous hardware clusters. However, they lack the necessary detection and expression of hardware dependencies within the container images or composed applications. DRAPS [START_REF] Mao | DRAPS: Dynamic and Resource-Aware Placement Scheme for Docker Containers in a Heterogeneous Cluster[END_REF] focuses on resource allocation, and thus in quantitative differences in CPU performance, amount of RAM and network/block device I/O latency, whereas our work investigates hardware differences at a deeper and qualitative level. Our work is complementary and necessary to further improve heterogeneous cloud application orchestration with upfront predictability about the likelihood of failure.

Dockemu extends the network simulator NS-3 with portable containers to cover IoT scenarios [START_REF] Portabales | Dockemu: Extension of a Scalable Network Simulation Framework based on Docker and NS3 to Cover IoT Scenarios[END_REF]. It supports heterogeneity in nodes and links between them, but does not cover hardware differences in detail. We anticipate the use of our results for building better heterogeneous cloud simulators and emulators.

The metadata expressivity limitation of Docker Hub and privately deployed container image registries have been widely covered by researchers. ConHub [START_REF] Tian | ConHub: A Metadata Management System for Docker Containers[END_REF] is an extended metadata management system for Docker images on top of a relational database. It supports CQL queries and user-defined metadata, letting users manage hardware-dependent images when importing augmented metadata, similar to the ones we propose. Similarly, Docker2RDF [START_REF] Ayed | Docker2rdf: Lifting the docker registry hub into rdf[END_REF] and Dock-erFinder [START_REF] Brogi | DockerFinder: multi-attribute search of Docker images[END_REF] offer queryable endpoints that will benefit from richer descriptions including on hardware restrictions at pull time. While we focus on hardware features, studies exist [START_REF] Cito | An Empirical Analysis of the Docker Container Ecosystem on GitHub[END_REF] to analyse image content in terms of programming languages, runtimes, security vulnerabilities and reproducible builds, leading to further metadata.

Conclusion and Future Work

Our multi-method analysis on Docker container images identified limitations on the handling of heterogeneous hardware, an increasingly relevant matter in typical container environments such as differentiated cloud services. We released a new DockerHub dataset on the metadata of ∼11'000 Docker images over the period of more than one year. We offer insights on available and used hardware features, e.g., related to security (SGX) and machine learning (Nvidia). We validated initial search findings with static analysis, and cross-validated those with runtime testing. Further, we contributed new proposals to augment the container image metadata with hardware, device and volume information as well as tools to exploit the knowledge at runtime for more user-friendly application handling. Overall, we observed a solid growth of images and tags across architectures, with the exception of x386, whilst a low number of non-toy, non-base images exploiting specific hardware beyond the basic CPU architecture. As future work, we aim at extending container image quality benchmarks with hardware details, and look further into enclaved and isolated application execution in the cloud.

Data and Code

Metadata, analysis data, tools and code for reproducibility are made publicly available at https://doi.org/10.5281/zenodo.4531795.

Fig. 2 :

 2 Fig. 2: Monitoring metrics for Nov 11, 2019 to Feb 4, 2021

Fig. 3 :

 3 Fig. 3: Our methodology to gather and validate DockerHub's image data/metadata.

Fig. 4 :

 4 Fig. 4: Data-driven process: from experiment (steps ,,) to augmented metadata usage (,); dockerhub-collector, imagexplore, and hdocker are open-source.

Fig. 5 :

 5 Fig. 5: Images updated and data uploaded from Sept'19 until Feb'21; y2axis (right side): inbound network traffic originated by updates of the images on the y1axis.

Fig. 6 :

 6 Fig. 6: Active users by day from Sept'19 until Feb'21.

Table 1 :

 1 Automated static analysis of the SGX, Nvidia and library container samples.

		SGX	Nvidia Library
		images	images images
	Count	67	36	164
	Successfully retrieved	62 (93%)	14 (39%) 156 (95%)
	Cumulative disk size	61 GB	15 GB	75 GB
	Hardware dep detection correctness 58 (94%)	10 (71%) 152 (98%)
	Detection time	1876.7 s	211.0 s	1080.4 s
	Exceptions	False pos.	False pos. False neg.
	Excepted images	sgx-django,	egx-*,	odoo, crux,
		sgx-bootstrap, eac	sourcemage
		sgx-cosmos,
		payload-ethash

Table 2 :

 2 Device files in the SGX and library container samples.

		SGX	Nvidia Library
		images	images images
	Average /dev layers 2.1	1.0	1.0
	Multiple /dev layers 10 (15%)	0 (0%)	8 (5%)
	Shadow /dev files 27..36 (53%) 1..2 (14%) 6..11 (7%)
	Further /dev files	27 (40%)	1 (7%)	3..8 (5%)

  Listing 1.3: Pass-through support.

	1 {
	2	" platform " as defined above
	3	. . .
	4	" passthru-devices " : [
	5	"/ dev / kvm " , "/ dev / net / tun " , "/ dev / bus "
	6	] ,
	7	" volumes " : [
	8	"/ run / secrets " , "/ var / run / docker . sock "
	9	] }

Docker Hub: https://hub.docker.com/

Red Hat Registry: http://quay.io, Tenable: http://tenable.io

42nd rev https://lore.kernel.org/lkml/20201214114200.GD26358@zn.tnic/

MAO: https://mao-mao-research.github.io/


domain: phys sdv

text:
Térence Desclaux

Paul Duru

Pierre Joseph

Morgan Delarue

Olivier Liot

Top of the clog Pore y x Flux

Introduction Results

Analysis of collective displacements and local rearrangements The capture of solid particles in a porous medium is essential in many fields such as liquid chromatography, or infiltration of groundwater 1 . However, these processes have a major drawback: the porous media can get fouled and eventually clogged. The amount of accumulated solid matter can get so high that it forms a cake that blocks the flow of fluid and matter. Fundamentally, clogging is based on various processes, that occupy a wide variety of spatio-temporal scales. In the past, it has been extensively studied at the macroscopic scale, but information at the pore scale has remained inaccessible until the use of microfluidic devices 2 . Today, the clogging of a pore by rigid and inert particles is well documented 3 , and the use of deformable particles is starting to be reported 4 . But the study of bio-clogging -clogging with biological objects -opens many topical research questions: living cells have particular properties that can impact both the clogging scenario and the properties of the resulting clog. They are deformable, anisotropic objects endowed with adhesion mechanisms and behaviors specific to the living world (division, respiration, death). A well-reported consequence of these particular properties is that the cake is compressible 5 : its volume changes with hydro-mechanical constraints. At the microscopic scale, it is believed that this is a result of particle deformation and/or particle rearrangements, but this could not be directly observed in filtration systems. Moreover, that compressibility is reported to be reversible 6 : at the macroscale, the hydraulic resistance of the cake, at a given pressure, is independent of whether the cake has been exposed previously to higher pressures. At present, there is no explanation for the essentially reversible nature of microbial cake compression. The object of this work is therefore the study of the clogging of a model pore by biological particles with well-controlled properties: the baker's yeasts, Saccharomyces cerevisiae, in particular with regard to cake compressibility.

1/ Yeast suspension

  an optimal affine transformation to join images → Collective displacements (𝜹) 4/ Quantify the non affine component (squared difference) → Local rearrangements Affiliations a: IMFT, MPB team, 2 Allée du Professeur Camille Soula, 31400 Toulouse b: LAAS-CNRS, MILE team, Université de Toulouse, CNRS, INP, 7 Avenue du Colonel Roche, 31400 Toulouse Corresponding author : Térence Desclaux (terence.desclaux@imft.fr) References : 1-Zhang, Wei et al., 2012. « A Review of Colloid Transport in Fractured Rocks ». Journal of Mountain Science 2-Wyss, Hans et al., 2006. « Mechanism for Clogging of Microchannels ». Physical Review 3-Dressaire, Emilie, et Alban Sauret. 2017. « Clogging of Microfluidic Systems ». Soft Matter 4-Bouhid de Aguiar, et al., 2017. « Deswelling and Deformation of Microgels in Concentrated Packings ». Scientific Reports 5-Foley, G., 2006. « A review of factors affecting filter cake properties in dead-end microfiltration of microbial suspensions ». Journal of Membrane Science 6-Mccarthy, et al., 1999. « CHARACTERISATION OF CAKE COMPRESSIBILITY IN DEAD-END MICROFILTRATION OF MICROBIAL SUSPENSIONS ». Chemical Engineering Communications 7-Cerbino, R. et al. 2021 « Disentangling collective motion and local rearrangements in 2D and 3D cell assemblies ».

-

  Culture in Synthetic Complete Dextrose (SCD) Broth, mixed with iodixanol solution. → Medium density = Cellular density -Exponential phase of growth -10 5 cell / mL NO PROLIF PROLIF 2/ Cake growth -Suspension pushed through silicon-glass micro-model -Δ𝑃 = 400 mbar during 1 hour 3/ Compression/Decompression cycles -Δ𝑃 ∈ [ 400 mbar ; 1000 bar ] -Step size = 100 mbar.min -1 > Before cycles: no movements. > Final state: smaller clog than initial state Displacement dynamics at y = 100 µm > Before cycles: upward movements (cell proliferation)

Displacement profiles

> Displacements are the larger at first compression > 2 nd cycle : 𝜹 𝒄𝒐𝒎𝒑𝒓𝒆𝒔𝒔𝒊𝒐𝒏 = -𝜹 𝒅𝒆𝒄𝒐𝒎𝒑𝒓𝒆𝒔𝒔𝒊𝒐𝒏 > 1 st cycle = 2 nd cycle > 𝜹 𝒅𝒆𝒄𝒐𝒎𝒑𝒓𝒆𝒔𝒔𝒊𝒐𝒏 > 𝜹 𝒄𝒐𝒎𝒑𝒓𝒆𝒔𝒔𝒊𝒐𝒏

Rearrangements profiles

> Large rearrangements at 1 st compression, no rearrangements after.

> Same rearrangements at 1 st or 2 nd compression > Rather large rearrangements at decompression


Méthodologie d'évaluation multicritère de la qualité de la viande bovine CONANEC A. (1, 2, 4), RAMADAN L. (1), CHRIKI S. (3), ELLIES-OURY M-P. (1, 4)

INTRODUCTION

Le plan stratégique de la filière viande bovine, clarifié fin 2017 dans le cadre des états généraux de l'alimentation, repose sur deux objectifs : satisfaire davantage les attentes des consommateurs pour encourager la consommation de viande bovine, et assurer une rémunération des acteurs de la filière pour pérenniser les cheptels français et dégager des marges pour investir et innover dans l'outil de production [START_REF] Jentzer | Conférence Grand Angle Viande[END_REF]. Pour y parvenir, une démarche de montée en gamme des produits est privilégiée, via une augmentation des ventes de viandes sous des signes d'identification de l'origine et de la qualité (SIQO) (Carlhian 2018). Adapter les cahiers de charges de ces certifications avec l'engagement sociétal du PACTE rapporté par le RSO (Interbev 2020) est un défi majeur, compte tenu de la multiplication des enjeux (préservation de l'environnement, respect du bien-être animal, rémunération des acteurs et amélioration de la qualité des produits) et des nombreux critères pour les évaluer. L'échelle à laquelle sont évalués ces critères peut varier de façon marquée (morceau commercialisé, muscle, animal, troupeau, exploitation, filière) c'est pourquoi, dans une première partie, un focus sur l'animal et la qualité de ses produits sera réalisé dans cette communication. Selon l'Afnor (ISO 9001), la qualité peut être définie comme « l'ensemble des propriétés d'un aliment qui lui permet de répondre aux besoins exprimés ou implicites d'un utilisateur ». L'Expertise Collective (ESCo) sur « la qualité des aliments d'origine animale » (Prache et Santé-Lhoutellier 2020) s'est appuyée sur cette définition pour proposer sept propriétés permettant d'évaluer la qualité de la viande (Figure 1). Les méthodes de décision multicritère sont des outils mathématiques qui permettent d'accompagner le décideur dans la modélisation de ses préférences, puis de déterminer le compromis qui y répond le mieux. L'objectif de ce papier sera donc de présenter le principe et le potentiel de ces méthodes multicritères pour accompagner les acteurs de la filière à construire des cahiers des charges au plus près des exigences et préférences qu'ils auront formulées, notamment vis-à-vis des trois propriétés de la qualité de la viande bovine précédemment évoquées .

LES INDICATEURS DE LA QUALITE

Pour évaluer la qualité de la viande sur ses propriétés organoleptique, nutritionnelle et commerciale, une revue de la littérature a été réalisée.

PROPRIETES ORGANOLEPTIQUES

La définition de la qualité organoleptique d'une viande bovine varie en fonction du morceau et du débouché considéré (Touraille, 1994). Dans cette étude, seule la qualité des pièces bouchères (principalement le faux filet) à griller ou à rôtir a été traitée puisque c'est avant tout la qualité organoleptique de ces morceaux qui est décrite comme variable et susceptible d'influencer l'acte de réachat du produit (Hocquette et al. 2014). La qualité organoleptique de la viande bovine est traditionnellement évaluée lors de séances d'analyse sensorielle soit par un panel de consommateurs naïfs soit par des jurés entraînés qui attribuent une note à un triptyque de descripteurs : la tendreté, la jutosité et la flaveur (Monin 1991). Pour évaluer la tendreté, qui est considérée comme l'un des indicateurs le plus important par les consommateurs (Grunert et al. 2004), il existe aussi une mesure mécanique basé sur la force nécessaire pour cisailler un échantillon donné. La méthode de Warner-Bratzler est moins coûteuse et plus répétable que l'indicateur de tendreté obtenu en analyse sensorielle et leur corrélation semble forte (Lorenzen et al 2003), -0,60 en moyenne, allant de -0,26 à -0,95 selon les expérimentations (Guillemin et al 2009). Au cours de l'acte d'achat, les consommateurs associent la couleur à un indicateur de fraîcheur (Henchion et al. 2014) bien que les variations de la couleur semblent liées à des facteurs différents (Mancini et Hunt 2015). Un suivi de la couleur de la viande doit donc être réalisé, à partir du spectre chromatique CIE L*a*b* qui fournit trois indicateurs objectifs. La couleur du gras fait aussi l'objet d'une attention particulière, notamment parce qu'une ration à l'herbe peut entraîner une coloration jaunâtre [START_REF] Moloney | [END_REF], parfois vue d'un mauvais oeil par le consommateur.

PROPRIETE NUTRITIONNELLE

L'amélioration de la qualité nutritionnelle de la viande fait partie des engagements sociétaux du PACTE pour retrouver la confiance des consommateurs. La viande présente en effet de nombreux atouts nutritionnels dans l'alimentation mais sa surconsommation peut entraîner des maladies cardiovasculaires liées à sa forte teneur en acides gras saturés (AGS) (Mota et al. 2019). Le profil de la composition en acides gras est donc un premier indicateur. A noter qu'il existe un débat sur cet indicateur, exprimé parfois en teneurs (mg/g de muscle) parfois en proportions des lipides totaux. Exprimer les acides gras en teneur est plus concret, car il permet de quantifier l'apport effectif de chaque acide gras par la viande. Cependant une forte corrélation entre les différents acides gras est observée (en lien notamment avec la teneur en lipides totaux de la viande) et ne permet pas, par conséquent, de discriminer la qualité de la viande à partir de sa composition lipidique. Pour passer outre cette difficulté, il est possible d'exprimer ces indicateurs en proportion de la teneur lipidique du muscle. Toutefois cette approche nécessite de prendre en considération le fait qu'une viande ayant une forte proportion en oméga 3 (w3) ne contribue pas forcément à un apport conséquent en oméga 3 en quantité, cela peut aussi être dû à une quantité d'oméga 6 très faible. Les rapports tels que AGS/AGPI (acides gras polyinsaturés) et w6/w3 sont aussi une solution pour étudier cet aspect nutritionnel [START_REF] Wood | New aspects of Meat Quality[END_REF]. Le fer est un composant important des viandes rouges et est surtout très bio-disponible notamment dans sa forme héminique qui est jusqu'à 3 fois plus absorbable par l'intestin que sa forme libre (Turhan et al. 2004). Cela permet notamment de lutter contre l'anémie, assez courante chez les femmes par exemple. Cependant, il favorise aussi le potentiel oxydatif au niveau de l'intestin et serait donc aussi un facteur de risque de développement d'un cancer du côlon (Bastide et al. 2011). Cela montre que la qualité nutritionnelle de la viande est dépendante des consommateurs auxquels elle s'adresse (sexe, âge, régime alimentaire, problèmes de santé, etc.). Des vitamines absentes dans les produits végétaux, comme la carnitine et la B12, ont également des propriétés intéressantes [START_REF] Pereira | [END_REF].

PROPRIETE COMMERCIALE

La production française de bovin est très diverse de par 1) les deux origines (races laitières et allaitantes) aux fonctions de production très éloignées, 2) l'élevage de races pures et 3) la conduite de la finition des animaux peu standardisée [START_REF] Micol | Viande bovine en France. Quels types de production pour quels produits ? In[END_REF]

EVALUATION MULTICRITERE

La multiplication des indicateurs permettant d'évaluer les 3 propriétés étudiées (tableau 1) nécessite un travail de modélisation multicritère afin de réaliser une synthèse à l'image des préférences du décideur. A terme, l'objectif de cette méthodologie est de sélectionner la conduite de l'animal et de la transformation satisfaisant au mieux ces préférences.

LES PRE-REQUIS

Pour mettre en place une analyse multicritère, il est nécessaire de disposer d'un ensemble de n actions alternatives parmi lesquelles un décideur souhaite en sélectionner un nombre limité. Ces n actions dans le cas présent sont n viandes ayant été produites dans des conditions différentes et évaluées sur m critères (les indicateurs du tableau 1). La première étape consiste à faire un premier tri parmi cet ensemble de critères. Un critère fortement redondant avec un autre ou présentant un fort taux de valeur manquante peut justifier l'abandon de ce critère. Il est parfois possible d'imputer les valeurs à partir de techniques décrites par Josse et Husson (2016), ou de supprimer une action présentant des valeurs manquantes sur beaucoup de critères. Lorsque tous les critères ne sont pas exprimés dans la même unité (les critères sont dits « non commensurables »), il peut être utile de procéder à une normalisation afin de s'affranchir des unités lors de la fixation des poids (partie 2.2). L'exercice de standardisation des critères doit aussi permettre d'homogénéiser les différents objectifs : minimisation ou maximisation. Par exemple, on souhaitera maximiser la tendreté d'un morceau de viande mais minimiser la teneur en AGS. On pourra alors minimiser l'opposé de la tendreté afin de maximiser cette dernière. Si l'objectif d'un critère est d'atteindre une valeur cible, par exemple l'état d'engraissement dont la note doit se rapprocher de 3, la solution sera alors de minimiser l'écart du critère à la valeur cible (ici 3), ce qui permettra de rester dans un problème de minimisation pour tous les critères.

L'ATTRIBUTION DES POIDS

La préférence du décideur passe, dans la majorité des techniques d'agrégation (partie 2.3), par l'attribution d'un poids w à chaque critère. Pour fixer ces poids, le décideur peut se fier à sa propre expérience, ou se référer à un groupe d'experts comme dans l'étude menée par Conanec et al. (2019) pour l'attribution du poids de chaque acide gras dans l'évaluation de la qualité nutritionnelle. Cependant, même pour un groupe d'experts, l'exercice consistant à attribuer un poids entre 0 et 1 à un critère est pour le moins délicat. Parmi les outils d'aide existants (Wang et al. 2009), le plus couramment utilisé dans de nombreux domaines, comme l'énergie, l'environnement et l'économie notamment, est l'Analytic Hierarchy Process (AHP) (Mardani et al. 2015). Cette technique repose sur une évaluation de l'importance relative de chaque critère deux à deux (Saaty 2014), par une échelle d'entier allant de 1 (pas de préférence) à 9 (forte préférence d'un des deux critères). Stocké dans une matrice carrée W, ses préférences sont ensuite agrégées pour obtenir un poids global pour chaque critère. Un exemple de matrice ainsi que la formule d'agrégation des poids deux-à-deux est donnée en (eq. 1).

(1) Malgré l'appui de ces outils mathématiques, la quantification des poids reste subjective. A l'inverse, une méthodologie totalement objective devrait reposer sur une étude statistique cherchant à expliquer une préférence (acte d'achat ou pas par exemple) avec les indicateurs associés. C'est ce qui a été réalisé par le système MSA en créant le score Meat Quality 4 (MQ4) en recherchant le modèle linéaire permettant d'expliquer l'appréciation de la viande par des consommateurs à partir de la tendreté, la jutosité, la flaveur et l'appréciation globale (Polkinghorne et al. 2008). Cependant, le processus est coûteux nécessite de disposer d'un indicateur objectif global à décomposer.

L'AGREGATION ET LA DECISION

L'objectif des nombreuses techniques d'agrégation (Wang et al. 2009), est d'éclairer le décideur sur la ou les solutions qui sont les plus pertinentes au vu des préférences indiquées (via AHP par exemple). L'une des techniques les plus simples consiste à agréger par une somme les indicateurs pondérés par les poids w correspondant. Il en résulte un indice synthétique, qui permet d'ordonner les actions de la meilleure à la plus mauvaise. Bien que des variantes permettant d'améliorer cette méthode existent, la création d'un indice synthétique présente un inconvénient majeur : elle autorise la compensation entre indicateurs. Or, même si parfois le décideur n'apporte pas une grande importance à un indicateur, il n'envisage pas que celui-ci descende sous un certain seuil. Par exemple, un décideur ayant pour objectif de proposer une viande saine pourra choisir de rejeter une viande dont l'indice synthétique est le meilleur, car ayant une tendreté très mauvaise ce qui pourrait être rédhibitoire pour le consommateur. Une autre famille de méthodes multicritères existe pour répondre à ce problème : les méthodes de surclassement. Les informations nécessaires pour modéliser les préférences du décideur sont plus complètes. Par exemple, la méthode ELECTRE [START_REF] Roy | Reading in multiple criteria decision aid[END_REF]) nécessite, en plus des poids w, la définition de plusieurs seuils. Le seuil d'indifférence, au-dessous duquel une différence entre deux actions sur un critère donné n'est pas considérée comme traduisant une différence de préférence. Le seuil de préférence au-dessus duquel cette différence est jugée importante. Entre les deux seuils, on parle de préférence faible. Un seuil « véto » peut également être ajouté, permettant d'éliminer toute action ayant une performance trop moyenne sur l'un des critères (la tendreté selon notre exemple précédent). A partir des poids normalisés et de ces seuils, une fonction de concordance (reposant sur un système d'élection) permet de calculer un indicateur entre 0 et 1 permettant de trancher le rapport de préférence entre deux actions. Avec cette méthode, un classement ordonné des actions n'est pas toujours possible du fait de l'existence de l'indifférence et de la préférence faible. Moins lisibles, ces méthodes sont néanmoins plus adaptées à la réalité du terrain, où parfois, en raison d'un manque d'information, il n'est pas possible de trancher objectivement entre deux actions.

PERSPECTIVE D'UTILISATION DES METHODES MULTICRITERE

Pour être pertinent, ce type d'approche doit comparer un grand nombre d'animaux ayant été élevés et transformés dans une diversité de conditions. Ce travail est en cours de réalisation en fusionnant les bases de données des instituts technique (IDELE) et de recherche français (INRAE) et étrangers (Agroscope, Teagasc). Au terme de ce projet, un outil sera créé pour accompagner les acteurs de la filière lors de l'élaboration d'un cahier des charges. La saisie de leurs préférences via les méthodes précédemment décrites permettra à la fois de visualiser les performances atteignables et la conduite de l'animal à mettre en place pour obtenir ce résultat. La force de l'outil résidera sur l'expérience de nombreuses études qui permettront aussi, par des méthodes non détaillées ici, de prendre en compte le niveau incertitude de la décision. La réussite de ce projet est donc données-dépendante mais à l'heure actuelle, la base de données rassemble des animaux sur lesquels tous les indicateurs ne sont pas disponibles.

Enfin, l'enjeu de l'évaluation fine de la qualité des produits est à relativiser car on observe, pour l'heure, une simplification des indicateurs globaux de qualité, comme le Nutri-Score ou le NOVA qui ne prennent pas en compte la variabilité intra-produit pour juger des propriétés nutritionnelles de la viande.

Figure 1

 1 Figure 1 Les 7 propriétés de la qualité de l'aliment selon la définition de l'ESCo sur « la qualité des aliments d'origine animale » (Prache et Santé-Lhoutellier 2020).

  Dans cette communication, trois d'entre elles ont été développées : les propriétés organoleptique, nutritionnelle et commerciale. Une évaluation de ces propriétés est permise par la mobilisation de nombreux indicateurs. Un défi majeur lors de la création d'un cahier des charges avec un grand nombre d'indicateur, est l'existence d'antagonismes entre eux. Cela nécessite la mise en place de compromis comme les travaux de Ellies-Conanec et al. (2019), cette décision repose avant tout sur la modélisation numérique des préférences du décideur. Dans leurs travaux, les auteurs s'appuient sur l'avis d'experts de la viande issus d'instituts technique et de recherche français (IDELE, INRAE) et sur la grille de notation australienne Meat Standards Australia (MSA, Polkinghorne 2008) pour pondérer de manière relative l'importance de chaque indicateur selon la préférence du décideur. La pondération élaborée par le système MSA repose sur une décomposition statistique de la préférence des consommateurs à l'aide des indicateurs d'analyse sensorielle cités précédemment (tendreté, jutosité, flaveur) et d'une note d'appréciation globale du produit.

	Oury et al. (2016) l'ont montré (entre propriétés
	organoleptique, nutritionnelle et commerciale) via une
	double analyse factorielle : analyse en composantes
	principales de « clusters d'indicateurs » préalablement
	construit sur la base de forte corrélation entre eux. Conanec
	et al. (2019) ont également proposé une méthode originale
	de gestion des compromis pour étudier le lien entre
	propriétés nutritionnelle et organoleptique. Ces deux études
	reposent sur l'analyse de jeux de données comprenant un
	ensemble d'indicateurs décrivant les propriétés sensorielles
	(notes de tendreté, jutosité et flaveur attribuées lors d'une
	analyse sensorielle), les propriétés nutritionnelles (le profil
	des acides gras) du muscle Longissimus thoracis
	(entrecôte) et les performances animales (poids, note
	d'engraissement et conformation de la carcasse).

L'enjeu de ce processus de recherche d'un compromis, est de sélectionner la conduite technique de l'animal et les paramètres de transformation de la viande qui satisfassent au mieux les préférences exprimées par le décideur (un industriel ou un label par exemple). Or, comme souligné par

  . La propriété commerciale peut être défini comme la valorisation économique des animaux et des carcasses. En France et en Europe, cette propriété n'est pas forcément liée aux attentes des consommateurs finaux(Bonny et al. 2016). En effet, la grille EUROP rémunère les carcasses d'une catégorie donnée d'animaux en fonction de trois critères : le poids, la conformation EUROP et la note d'état d'engraissement. Une conformation importante (E, U) témoigne d'une qualité bouchère permettant notamment l'extension de découpe et donc une meilleure valorisation de certains muscles. La note d'engraissement de 1 à 5 est, quant-à-elle, optimale autour de 3. En dessous, le manque de gras ne permet pas une conservation idéale de la viande lors de la maturation. Au-dessus, une carcasse trop grasse diminue le rendement en viande et mécaniquement la marge du transformateur. Ces tendances sont confirmées par la récente enquête menée en Aquitaine auprès de professionnels de la transformation (Ellies-Oury et al. 2020). La couleur de la viande et la teneur en persillé, sont les deux critères les plus cités par ces transformateurs en réponse à la question : « quels sont les critères de qualité d'une carcasse de bovin ». Ces indicateurs font d'ailleurs partie de la rémunération des producteurs dans des pays ayant d'autres systèmes de classification. En Australie, le persillé et la couleur sont évalués au niveau de la 10 ème côte. Aux États-Unis et au Japon, des indicateurs de gras péri-rénaux permettent d'évaluer plus finement le rendement en viande, car davantage corrélé que la note de l'état d'engraissement des carcasses(Polkinghorne et Thompson 2010).Monteils et al. (2017) proposent d'ailleurs l'adoption du persillé comme nouveau critère de paiement des carcasses en France et en Europe. Le développement de Meat@ppli (Normand et al. 2019), une application smartphone permettant d'évaluer, à partir d'une simple photo, le persillé d'une viande, symbolise l'intérêt que porte la filière à cet indicateur dont l'évaluation en routine est en phase de thèse en abattoir[START_REF] Jentzer | Conférence Grand Angle Viande[END_REF]).

	Une proposition de 8 principes pour évaluer les trois
	propriétés est résumée dans le tableau 1. Chaque principe
	est ainsi évalué au travers d'un ou plusieurs indicateurs qui
	seront réutilisés dans l'analyse multicritère en seconde
	partie.
	Tableau 1 Tableau récapitulatif d'une proposition
	d'indicateurs permettant d'évaluer la qualité de la viande
	bovine selon les 3 propriétés enquêtées.
	Propriété	Principe	Indicateurs
	Organoleptique	Analyse	Tendreté, jutosité,
		sensorielle	flaveur
		Rhéologie	Force de
			cisaillement
	Nutritionnelle	Acides gras	AGS/AGPI, w6/w3
		Vitamines	B12, carnitine
		Oligo-éléments	Fer, zinc
	Commerciale	Morceaux nobles Conformation,
			poids de carcasse
		Rendement en	État
		viande	d'engraissement,
			gras péri-rénaux
		Indice de qualité	Couleur, persillé
		consommateur

Renc. Rech. Ruminants, 2020, 25