• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 118
  • 37
  • 29
  • 29
  • 16
  • 12
  • 8
  • 6
  • 6
  • 3
  • 1
  • 1
  • 1
  • 1
  • Tagged with
  • 303
  • 77
  • 54
  • 44
  • 44
  • 39
  • 31
  • 29
  • 24
  • 22
  • 22
  • 21
  • 20
  • 20
  • 19
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
21

Purely top-down software rebuilding

Grosskurth, Alan January 2007 (has links)
Software rebuilding is the process of deriving a deployable software system from its primitive source objects. A build tool helps maintain consistency between the derived objects and source objects by ensuring that all necessary build steps are re-executed in the correct order after a set of changes is made to the source objects. It is imperative that derived objects accurately represent the source objects from which they were supposedly constructed; otherwise, subsequent testing and quality assurance is invalidated. This thesis aims to advance the state-of-the-art in tool support for automated software rebuilding. It surveys the body of background work, lays out a set of design considerations for build tools, and examines areas where current tools are limited. It examines the properties of a next-generation tool concept, redo, conceived by D. J. Bernstein; redo is novel because it employs a purely top-down approach to software rebuilding that promises to be simpler, more flexible, and more reliable than current approaches. The details of a redo prototype written by the author of this thesis are explained including the central algorithms and data structures. Lastly, the redo prototype is evaluated on some sample software systems with respect to migration effort between build tools as well as size, complexity, and performances aspects of the resulting build systems.
22

Opportunities And Barriers Of Architect Led Design Build Projects

Deniz, Ayca 01 November 2012 (has links) (PDF)
ABSTRACT OPPORTUNITIES AND BARRIERS OF ARCHITECT LED DESIGN-BUILD PROJECTS Deniz,Ay&ccedil / a M.Sc. in Building Science, Department of Architecture Supervisor: Assoc. Prof. Dr. Soofia Tahira Elias Ozkan September 2012, 77 pages From past to today, technological developments have resulted in new systems in parallel with digital age. Innovations have been started to be replaced with the traditional solutions. Standardizations have also started to be renewed in accordance with the high technology and complexity of the projects. Under these circumstances, design and construction activities have been separated in the construction industry. As a result, alternative project delivery systems have been developed and selecting the right delivery system has gained importance depending upon the complexity of the projects The main objective of this study was to propose a model that supports architect&rsquo / s leadership in design-build systems throughout an international airport project as a case study. Thus, construction industry will gain awareness for the organization structures in which architectural groups lead the other disciplines to achieve success in design-build systems considering time cost quality triangle. In this study, organization charts including project construction process and factors affecting design and construction activities were investigated. The matrix relationship in production level of the organization charts among the project disciplines has been analyzed. According to the evaluation of models reflecting the existing status, alternative models supporting architect&rsquo / s leadership are proposed.
23

Uma avaliação comparativa entre os métodos design-build e o design-bid-build para redução de problemas entre projeto e contrução de obras públicas brasileiras

ALBUQUERQUE, Ana Elisabete Cavalcanti de 31 May 2012 (has links)
Submitted by Suethene Souza (suethene.souza@ufpe.br) on 2015-03-03T18:32:34Z No. of bitstreams: 2 DissertacaoDesignBuild.pdf: 3398710 bytes, checksum: ef609f38cfa0477d8bd3c9f076675594 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-03T18:32:34Z (GMT). No. of bitstreams: 2 DissertacaoDesignBuild.pdf: 3398710 bytes, checksum: ef609f38cfa0477d8bd3c9f076675594 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2012-05-31 / Este estudo objetiva identificar as contribuições do método design-build, bem como riscos envolvidos na sua adoção, com vistas à minimização de problemas entre projeto e construção de obras públicas, oriundos em parte da dissociação entre projeto e construção imposta pela legislação brasileira ao determinar contratações distintas para ambos. Para que as contribuições do método fossem visualizadas foi necessário compará-lo ao que atualmente é utilizado pela Administração, método design-bid-build. Assim, foi realizado um estudo de caso de natureza qualitativa, no qual foram realizadas pesquisas documentais e de campo, na forma de entrevistas. Sobre os dados documentais e de campo foi aplicada análise de conteúdo, bem como triangulação de métodos e fontes, o que possibilitou investigar os problemas sob pontos de vistas diversos, captados por métodos diferentes, oferecendo um panorama bem mais próximo da realidade. Dentre os problemas identificados figuram falta de interação direta entre projetistas e construtoras, prazos irreais determinados pelo contratante para elaboração dos projetos e longo período de tempo entre concepção do projeto e efetiva execução da obra. Identificados os problemas foi verificado quais deles poderiam ser solucionados ou minimizados com a adoção do método de contratação design-build, considerando sua principal característica de concepção do projeto e execução da obra realizados por uma única empresa, em uma única contratação. Ao mesmo tempo, com vistas a uma possível adoção do método, foram levantados aspectos negativos, riscos prováveis e respectivas estratégias de enfrentamento. Dentre os aspectos críticos observados pelos entrevistados sobressaíram a possibilidade da empresa contratada se beneficiar elaborando um projeto ajustado às suas disponibilidades e não à real necessidade do contratante, associada à falta de estrutura dos órgãos públicos para exercerem o controle requerido pelo método design-build. Verificou-se que o método design-build seria uma solução possível para alguns dos problemas encontrados. Entretanto, o contratante deve precaver-se dos aspectos negativos e riscos possíveis, adotando medidas que eliminem ou minimizem seus efeitos. Os resultados encontrados contribuirão certamente não apenas para uma possível implantação do método, em contextos inclusive distintos do público, como também para a melhoria dos processos concernentes a projeto e execução de obras, independente do método de contratação porventura utilizado. No âmbito acadêmico poderá contribuir incentivando a realização de mais pesquisas sobre projeto e execução de empreendimentos de construção
24

Optimum Part Build Orientation in Additive Manufacturing for Minimizing Part Errors and Build Time

Das, Paramita 12 September 2016 (has links)
No description available.
25

Integration of Reproducibility Verification with Diffoscope in GNU Make / Integrering av reproducerbarhetsverifiering med diffoscope i GNU Make

Lagnöhed, Felix January 2024 (has links)
Software Supply Chain attacks are becoming more frequent. It is not enough to trust the source code of a project; the build process can insert malicious contents into build artefacts. This calls for the need of valid verification methods regarding the build process, and a good way of doing so is ensuring that the build process is deterministic. This means, that given two binaries built from the same source code and in the same environment, the resulting build artefacts should be bit-wise identical. There are existing tools that check this, but they are not integrated into build systems. This thesis resulted in an extension of GNU make which is called rmake, where diffoscope - a tool for detecting differences between a large number of file types - was integrated into the workflow of make. rmake was later used to answer the posed research questions for this thesis. We found that different build paths and offsets are a big problem as three out of three tested Free and Open Source Software projects all contained these variations. The results also showed that gcc’s optimisation levels did not affect reproducibility, but link-time optimisation embeds a lot of unreproducible information in build artefacts. Lastly, the results showed that build paths, build ID’s and randomness are the three most common groups of variations encountered in the wild and potential solutions for some variations were proposed.
26

Implementation of Post-Build Configuration for Gateway Electronic Control Unit : Gateway ECU to enable third-party update

Tanoh, Henry-Gertrude January 2018 (has links)
The development of embedded software in the automotive industry has reached a level of complexity, which is unmaintainable by traditional approaches. The AUTomotive Open System Architecture (AUTOSAR) was created to standardize the automotive software. In this architecture, the development of software is spread, in general, between three different entities: Original Equipment Manufacturers (OEMs), e.g. Volvo; Tier-1 Suppliers, such as Vector; and Tier-2 Suppliers, for example, Renesas Microelectronics. Another methodology that has emerged is to develop Electronic Control Units (ECUs) domain wise: infotainment, chassis & safety, powertrain, and body and security. To allow inter-domain communication, the state of art for fast and reliable communication is to use a gateway ECU. The gateway ECU is a crucial component in the electrical/electronic (E/E) architecture of a vehicle. In AUTOSAR, a third party, different from the car manufacturer, typically implements the gateway ECU. A major feature for a gateway ECU is to provide highly flexible configuration. This flexibility allows the car manufacturer (OEM) to fit the gateway ECU to different requirements and product derivations. This thesis investigates the implementation of post-build configuration for a gateway ECU. First, the thesis provides the reader with some background on AUTOSAR and the current E/E architecture of the gateway ECU. The protocols used by the gateway are explained. The design of a potential solution and its implementation are discussed. The implementation is evaluated through regression tests of the routing functionality. Processing time, memory use, and scaling of the solution are also taken into account. The results of the design and the implementation if judged adequate could be used as a springboard to allow post-build in an existing gateway ECU architecture. The results could consolidate the path towards full conformance to AUTOSAR. / Inbyggda system har ökat i fordonsindustrin. Utvecklingen av dessa inbyggda programvaror har varit komplex och är inte genomförbar per enhet. Idag är utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahåller elektroniska styrenheter (ECU) hardvaror. Förmedlingsnod ECU är en viktig komponent i ett fordons elektriska/elektroniska (E/E) arkitektur. En tredje part implementerar, som skiljer sig från OEM, de flesta funktionerna av den förmedlingsnod ECU. En viktig egenskap för en förmedlingsnod är att tillhandahålla en mycket flexibel konfiguration. Denna flexibilitet tillåter (OEM) att anpassa förmedlingsnod till olika kraven och fordonarkitekturer. Denna avhandling undersöker genomförandet av Post-build konfigurationen, ocksa kallad dynamisk konfigurationen för en förmedlingsnod ECU. För det första gers bakgrund på AUTOSAR och den nuvarande E/E arkitekturen för den ECU. De kommunikation protokoll som används förklaras. Utformningen av en potentiell lösning och dess genomförande diskuteras. Implementeringen utvärderas genom regressionstest av routingsfunktionaliteten. Behandlingstid, minneseffektivitet och skalning av lösningen beaktas också. Resultaten av konstruktionen och genomförandet om det bedömdes som lämpligt skulle kunna användas som ett springbräda för att möjliggöra postbyggnad i en befintlig förmedlingsnod arkitektur. Resultaten kan konsolidera vägen mot full överensstämmelse med AUTOSAR. / Le développement de systèmes embarqués dans l’industrie automobile a atteint un niveau de complexité très élevé. D’où la nécessité de créer de nouvelles méthodologies. AUTomotive Open Architecture (AUTOSAR) a été créé pour la mise place de standards pour le développement dans l’industrie automobile. Dans l’architecture AUTOSAR, le développement de logiciels embarqués est reparti, en général, entre trois partis : Original Equipement Manufacturer (OEM), Renault par exemple. Le deuxième niveau regroupe les fournisseurs de logiciels et outils, par exemple, Elektrobit. On retrouve en troisième position les Tier-2 suppliers, fournisseurs de cartes électroniques pour l’automobile, comme Renesas ST. Le développement de calculateurs est séparé par domaine : Multimédia, châssis, motorisation et intérieur. La communication inter-domaine passe par un calculateur passerelle. Le calculateur passerelle est essentielle dans l’architecture électronique du véhicule. Dans AUTOSAR, le calculateur est fourni par un tiers parti, différent du constructeur automobile. Il est donc nécessaire pour le constructeur d’être capable de configurer le calculateur passerelle, sans repasser par le vendeur. Par exemple, le constructeur peut décider, réception du software de rajouter une nouvelle route dans la passerelle. Cet aspect est connu sur le nom de Post-build Configuration dans AUTOSAR. Le but de ce stage est le design et l’implémentation de Post-build configuration d’un calculateur passerelle. D’abord, AUTOSAR et l’architecture électronique d’un calculateur passerelle sont détaillées. Les protocoles de communication sont aussi décrits. Ensuite, le design et les choix d’implémentation sont discutés. L’implémentation est évaluée avec des tests de régression sur les fonctionnalités de routage. Aussi, la solution finale est évaluée sur les critères de performance de routage, l’efficacité en consommation mémoire et la capacité d’être intégrée dans un produit final.
27

Implementation of Post-Build Configuration for Gateway Electronic Control Unit : Gateway ECU to enable third-party update

Tanoh, Henry-Gertrude January 2018 (has links)
The development of embedded software in the automotive industry has reached a level of complexity, which is unmaintainable by traditional approaches. The AUTomotive Open System Architecture (AUTOSAR) was created to standardize the automotive software. In this architecture, the development of software is spread, in general, between three different entities: Original Equipment Manufacturers (OEMs), e.g. Volvo; Tier-1 Suppliers, such as Vector; and Tier-2 Suppliers, for example, Renesas Microelectronics. Another methodology that has emerged is to develop Electronic Control Units (ECUs) domain wise: infotainment, chassis & safety, powertrain, and body and security. To allow inter-domain communication, the state of art for fast and reliable communication is to use a gateway ECU. The gateway ECU is a crucial component in the electrical/electronic (E/E) architecture of a vehicle. In AUTOSAR, a third party, different from the car manufacturer, typically implements the gateway ECU. A major feature for a gateway ECU is to provide highly flexible configuration. This flexibility allows the car manufacturer (OEM) to fit the gateway ECU to different requirements and product derivations. This thesis investigates the implementation of post-build configuration for a gateway ECU. First, the thesis provides the reader with some background on AUTOSAR and the current E/E architecture of the gateway ECU. The protocols used by the gateway are explained. The design of a potential solution and its implementation are discussed. The implementation is evaluated through regression tests of the routing functionality. Processing time, memory use, and scaling of the solution are also taken into account. The results of the design and the implementation if judged adequate could be used as a springboard to allow post-build in an existing gateway ECU architecture. The results could consolidate the path towards full conformance to AUTOSAR. / Inbyggda system har okat i fordonsindustrin. Utvecklingen av dessa inbyggda programvara har varit komplex och ar inte genomforbar per ett enhet. Idag ar utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahaller elektroniska styrenheter (ECU) hardvaror. Förmedlingsnod ECU är en viktig komponent i ett fordons elektriska/elektroniska (E/E) arkitektur. En tredje part implementerar, som skiljer sig från OEM, de flesta funktionerna av den förmedlingsnod ECU. En viktig egenskap för en förmedlingsnod är att tillhandahålla en mycket flexibel konfiguration. Denna flexibilitet tillåter (OEM) att anpassa förmedlingsnod till olika kraven och fordonarkitekturer. Denna avhandling undersöker genomförandet av Post-build konfigurationen, ocksa kallad dynamisk konfigurationen för en förmedlingsnod ECU. För det första gers bakgrund på AUTOSAR och den nuvarande E/E arkitekturen för den ECU. De kommunikation protokoll som används förklaras. Utformningen av en potentiell lösning och dess genomförande diskuteras. Implementeringen utvärderas genom regressionstest av routingsfunktionaliteten. Behandlingstid, minneseffektivitet och skalning av lösningen beaktas också. Resultaten av konstruktionen och genomförandet om det bedömdes som lämpligt skulle kunna användas som ett springbräda för att möjliggöra postbyggnad i en befintlig förmedlingsnod arkitektur. Resultaten kan konsolidera vägen mot full överensstämmelse med AUTOSAR. / Le développement de systèmes embarqués dans l’industrie automobile a atteint un niveau de complexité très élevé. D’où la nécessité de créer de nouvelles méthodologies. AUTomotive Open Architecture (AUTOSAR) a été créé pour la mise place de standards pour le développement dans l’industrie automobile. Dans l’architecture AUTOSAR, le développement de logiciels embarqués est reparti, en général, entre trois partis : Original Equipement Manufacturer (OEM), Renault par exemple. Le deuxième niveau regroupe les fournisseurs de logiciels et outils, par exemple, Elektrobit. On retrouve en troisième position les Tier-2 suppliers, fournisseurs de cartes électroniques pour l’automobile, comme Renesas ST. Le développement de calculateurs est séparé par domaine : Multimédia, châssis, motorisation et intérieur. La communication inter-domaine passe par un calculateur passerelle. Le calculateur passerelle est essentielle dans l’architecture électronique du véhicule. Dans AUTOSAR, le calculateur est fourni par un tiers parti, différent du constructeur automobile. Il est donc nécessaire pour le constructeur d’être capable de configurer le calculateur passerelle, sans repasser par le vendeur. Par exemple, le constructeur peut décider, réception du software de rajouter une nouvelle route dans la passerelle. Cet aspect est connu sur le nom de Post-build Configuration dans AUTOSAR. Le but de ce stage est le design et l’implémentation de Post-build configuration d’un calculateur passerelle. D’abord, AUTOSAR et l’architecture électronique d’un calculateur passerelle sont détaillées. Les protocoles de communication sont aussi décrits. Ensuite, le design et les choix d’implémentation sont discutés. L’implémentation est évaluée avec des tests de régression sur les fonctionnalités de routage. Aussi, la solution finale est évaluée sur les critères de performance de routage, l’efficacité en consommation mémoire et la capacité d’être intégrée dans un produit final.
28

Options to reduce sediment build-up in a surf zone trench protected by an open-ended cofferdam

Muller, Jacobus Johannes 03 1900 (has links)
Thesis ((MEng)--Stellenbosch University, 2015. / ENGLISH ABSTRACT: When constructing a submarine pipeline, construction teams must work in the hostile environment in the ocean known as the surf zone. The surf zone is the area along a shoreline stretching between the first evident point of wave breaking and the beach line. In order to ensure that the pipeline is shielded from the imposing forces within the surf zone, engineers use a burial technique which leaves the pipeline length in the surf zone buried underneath the active seabed once construction is finished. Thus a temporary surf zone trench is dredged and protected by an open-ended cofferdam built using iron sheet piles. As a result of the incoming wave climate and the surf zone currents created by this wave climate, sedimentation in and around the trench becomes problematic. In this study alternative geometric layouts for the open-ended cofferdam protecting the surf zone trench are investigated, attempting to minimize the sediment build-up in and around the trench. This was done by using both a 3D qualitative physical model conducted at the CSIR in Stellenbosch, and numerical model using MIKE developed by DHI. However, this study only considers sediment build-up and not structural integrity and constructability of the cofferdam designs. Combining the observations of both the physical- and numerical models, a conclusion was drawn that a structure built perpendicular to the shoreline with a 45oextended arm built from the upstream edge of the cofferdam wall, is the most effective. No dimensions are given as the cofferdam design will change depending on the site specific characteristics. Also an increase in structure length will result in the mouth of the structure being located outside the active sediment zone, which leads to a longer period of time before the pipeline pathway is compromised by sediment. / AFRIKAANSE OPSOMMING: Tydens die konstruksie van 'n onderwaterse pyplyn, moet konstruksie spanne in 'n gevaarlike gedeelte van die see werk naamlik die brandersone. Die brandersone kan gedefinieer word as die area tussen die eerste punt waar branders breek en die strandlyn. Om die pyplyn te beskerm teen die kragte wat branders op dit uitoefen, gebruik ingenieurs 'n installasietegniek waar hul die brandersone seksie van die pyplyn onder die aktiewe seebodem begrawe. Om die tegniek te bewerkstellig, grawe kontrakteurs 'n sloot deur die brandersone en beskerm dit met 'n tydelike struktuur bekend as 'n kofferdam. As gevolg van die inkomende branders en die strome wat deur die branders aangedryf word, kan die opbou van sediment in, en rondom die sloot in die brandersone problematies word. Hierdie studie ondersoek alternatiewe uitlegte vir die tydelike kofferdam struktuur met die oog daarop om die opbou van sediment in, en rondom die struktuur te verminder. Die doel was nagestreef deur gebruik te maak van beide 'n 3-dimensionele fisiese model, gebou en gebruik by die WNNR in Stellenbosch, en 'n numeriese model wat op MIKE, ontwikkel deur DHI gedoen was. Let wel die studie het slegs die sediment beweging in die nabye area van die tydelike kofferdam struktuur in ag geneem en nie die praktiese implimentering en strukturele integriteit van die struktuur nie. Deur die observasies van beide die fisiese- en numeriese modelering in ag te neem, is die volgende gevolgtrekkings gemaak. 'n Struktuur wat loodreg met die strandlyn gebou is en met 'n 45o arm wat na die stroom-op kant toe uitstrek, was die mees effektiewe een. Geen dimensies is deurgegee nie aangesien die ontwerp sal verskil afhangende van die spesifieke area waar die projek aangepak word. Daar is ook gesien dat indien die struktuur langer gemaak word, sal die kontrakteur langer tyd h^e voordat daar sediment probleme in die brander sone sloot ondervind sal word.
29

Investigating the structural frame decision making process

Haroglu, Hasan January 2010 (has links)
Structural frames are widely used in sectors such as residential, education, commercial, health, retail, leisure etc. and the selection of a structural frame appropriate to a building s function and client needs is a key decision with significant short- and long-term implications. There is a wide choice of structural frame materials for building projects, i.e concrete, steel, timber, or masonry. Although many options are available, these tend to be based on structural steel or reinforced concrete for the simplest buildings. The nature of concrete frame buildings has developed significantly with the emergence of new technologies and innovations particularly in formwork, concrete as a material, and reinforcement developments. As a result, concrete frame construction has become a faster, more sustainable, and safer form of construction. However, competition from other framing materials such as steel have proved challenging. This research was initiated in response to this challenge and represents one organisation s attempt to deliver improvements in order to promote concrete in the UK structural frames market. The organisation is strongly focused on the continued development of concrete through design inspiration and construction efficiency, research strategy, education and training, new product and process innovation and the achievement of best performance of concrete in practice. The research programme was established to address issues that are considered by decision makers when choosing the optimum frame solution for a building project, and to identify how such decisions are made in practice. Both quantitative and qualitative research methods have been adopted during the EngD research including a literature review, industry questionnaire survey and case study. From an initial set of interviews, ten key issues were identified at the early stage of the research as being the most important affecting the structural frame selection for a building project. The structural engineer was found, unsurprisingly, to be the most influential decision-maker in the choice of frame at each stage of design process from a subsequent survey of cost consultants, project managers and clients. The survey also revealed that Design-Build is the preferred procurement route amongst developers of building projects, ranging from complex, high quality projects to simple buildings which suggested that most contractors must be getting involved earlier in the design process and thus could be influencing major decisions, such as the selection of a structural frame. Four case study project teams were examined, from which it was clear that contractors could be influential in the frame selection process if they had the willingness to build in a particular frame type (provided that the frame type selected meets the client s requirements). Key findings on the choice of frame in a Design-Build project and the various actions taken by the contractor were highlighted by the research, including the important role played in the decision-making process by more informed clients, who are much more likely to be influential in deciding on the frame type. Further work could be carried out to assess the specific benefits of early contractor involvement, the factors that affect the extent to which contractors get involved with structural frame decision making and the risk relationship between client and contractor. The findings of this work have been presented in five peer-reviewed papers.
30

Instabilidade e variabilidade do indicador BTS (Build to Schedule) em linhas de montagem

Mendes , Pedro Daniel Gandarela de Oliveira January 2012 (has links)
Tese de mestrado integrado. Engenharia Industrial e Gestão. Faculdade de Engenharia. Universidade do Porto. 2012

Page generated in 0.0282 seconds